There are several considerations that enter into the mix. First of all,
serious question, how do you actually know that a Requirement will take 40
man-hours of actual work to produce? You may have some other method but
generally such estimates are based on historical performance and experience.
Most of the time, though, historical information about what was required to
do something falls more accurately into a record of the duration spent doing
it than it does an actual detailed record of the man-hours that the resource
doing it put in specifically on that task and that task alone. Knowing with
any accuracy that it took Joe 40 man-hours of work to complete a
Specification even though it was done over two week's duration with the
other 40 man-hours consumed by miscellaneous non-task activities would
require retaining a precise moment by moment ergonomic breakdown of the
activities of his workday and that sort detailed information is rarely, if
ever, going to be available. What is much easier to know from past
performance history is that when Joe starts work on a Specification similar
to this current job, he typically has it finished in two weeks - ie,
duration. But we know that during that historical two week duration, he
also spent some unknown percentage of the total time on imponderables -
email, voicemail, meetings, putting out fires, etc. So what we can say is
that some time away from the primary task for such typical routine
distractions is included in the 80 hour estimate. So if we put a duration
estimate of 80 hours to the task this time and Joe doesn't have
extraordinary interruptions that break the pattern, we can assign him 100%
and just ignore the fact that the 80 man-hours we're budgeting for the task
might really be 60 man-hours of solid goal-directed work plus 20 man-hours
of undifferentiated, time-consuming distractions. By assuming the task is
80 man-hours and assigning him 100% we effectively build in the allowance
for overhead into the time estimate for the task without trying to
micromanage something we probably can't really know much about with any
accuracy anyway. The bottom line is to answer the question "What date will
Joe finish the Requirements so we can move on to the next step in the
project?" and it really doesn't matter much whether it really took Joe
precisely 75.4 man-hours or 62.3 man-hours to do it after backing out the
time he spent on email, etc. As my college profs repeatedly reminded us
many years ago, never let precision in your calculations, the number of
decimal places you display, delude you into thinking you actually know
something with any certainty. Precision and accuracy are two different
things. IMHO, trying to say Joe's 8-hour workday is going to be spent as
5.4 hours on writing Requirements, 1 hour on email and voicemail, 1.25 hours
in staff meetings, etc is what my quantitative analysis and physics profs
called "empty precision." Or to use a cliche`, it's awfully easy to lose
sight of the forest because of all the trees.
Another practical consideration. The typical PM workflow in developing a
schedule is to define the task with a duration estimate, then assign
resources. Project itself calculates the work estimated for each task from
the duration estimate and the units assigned vie the classic W=D*U formula.
No matter what assignment percentage you use, for the initial assignment the
post-assigning duration will be the same as the pre-assigning duration.
Create a task with 5 days duration and assign Joe to it. If you put Joe on
at 100%, the plan will show that task as 5 days. But if you put Joe on at
50%, the plan will ALSO show the duration as 5 days. To get it to go to 10
days, you have to enter Joe at 100%, make sure the task is marked Fixed Work
or Fixed Units, and then in a second assignment edit, reduce him to 50%.
Either that, or add the Work column to the table and enter the work estimate
sthere (but as discussed above it's really difficult to have any accurate
knowledge of what that value ought to be), leaving the duration at the
default 1day? value, making sure they're Fixed Work, and letting Project
calculate duration at the time of the assignment.
HTH
Joe said:
Steve,
I would like your opinion on how I use allocation on my project plan
because
it is vastly different from the response you just provided.
I have 20 people working as business analysts. I have a project plan that
tracks the creation of requirements for a particular project. The task on
this plan is to produce requirement documents for the many functional
components of the system. On a typical project plan, I would have 20
Analyst
producing about 100 sets of requirements (5 per analyst). These analysts
have other responsibilities besides just producing these requirements.
For
example, if a production issue comes up, they may have to resolve that
first,
there are meetings to attend during the day that are not related to the
task
on the plan, On average, when someone is assigned to produce a
requirements
document, they can probably spend a solid 6 hours of an 8 hour day. The
other 2 hours would be attending meetings, answering e-mails, addressing
production issues, etc (which I have an administrative task set up for).
One
of the main purposes of the project plan is to see what date this
requirements phase of the project will be completed. If each requirement
(100 of them) is estimated to take 40 hours of work (note, not one week of
work, but 40 actual hours of work). Why would it not be a good idea to
assign each resource at 75% allocation? This way, after assigning all 100
items to the 20 analyst at 75% I know when they are expected to be
completed
assuming they will devote 6 hours a day. If I allocate them at 100%, I
will
get a false end date and I know we will not meet the date the project
plan
says because I know we will only produce 6 hours a day. So after one week
of
tracking actuals, I would be behind schedule if I use 100% allocation, but
on
track if I use 75% allocation.
In your opinion, why would I want to use 100% allocation?
Steve House said:
"Overallocation" means the instantaneous total allocation of a resource
has
exceeded the maximum allowed allocation. When the overallocation is
caused
by the allocation on two or more tasks that occur at the same totalling
more
than the max allowed, leveling can move one or more or the tasks out into
the future until the conflict is resolved. But delaying tasks is all it
ever
does. It NEVER changes the percentages that resources are assigned. So
if
you've assigned someone to Task X at 100% and then later reduce his
maximum
allowed to 80%, you've created an overallocation that leveling can't
resolve. What was an 8-hour task at 100% on Monday that has now been
moved
to Tuesday is still an 8-hour task at 100%, just now on a different day.
Now I have to ask ... why do you want your resources to only devote part
of
their energy to their work? If I assign a job to someone I expect them
to
give it their full attention while they're working on it. If I have a
task
that requires 6 hours of work, I expect them to focus on it for 6 hours
and
get it done in 6 hours, not go about it half-a**ed (okay, 3/4-a**ed <g>)
and
take 8 hours to do it. IMHO, less than 100% allocations only make sense
when someone really can do 2 things at the same time - let's say
reviewing a
document has an editor both checking spelling and checking technical
accuracy. If there's some reason the separate those functions into 2
tasks,
we might have them both going in parallel and assign the editor to them
50%
each. But other than odd-ball situations like that I suggest that
resources
be assigned 100%. The allocation percentage is not the percentage of the
workday the resource spends on the tasks - it is the rate at which the
resource's work converts time into deliverable. 100% means he generates
8
hours worth of Full Time Equivalent output for 8 hours of clock time
spent.
50% means he generates 4 hours of FTE output for 8 hours of clock time
spent. So a 4-hour task is not a 1 day duration task worked at 50%, it
is a
4-hour duration task worked at 100%.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit
http://www.mvps.org/project/faqs.htm for the FAQs
Hi,
I'm trying to allocate a team of 30 people @ 80% on a project. I'm
using
a
resource pool. I thought if I set the max units to 80% and leveled the
project it would apply this rule. However leveling is telling me that
there
is an overallocation on each resource.
Is there any way that I can apply 80% resource allocation on the
already
specified work. I don't really want to apply 80% on every task on the
plan.
Hope you can help with what seems like a simple problem !
