What is your opinion on using Max Units throughout a project file?

[Seann]

I want to limit the amount of hours a resource is available per day for
almost every resource in my project file. As everyone knows we typically do
not get a full 8hrs of productivity out each employees. Therefore I plan to
put all resources at a max unites ranging from 90% to as low as 40% for every
task they work on.

Does anyone have any feedback on the pros and cons of using this method?

 

[Joe]

This is exactly how I use it and it works fine.

 

[St Dilbert]

I would support you in trying to limit availability to less than the
"contracted hours present" - this will yield more realistic schedules.

I personally limit the working hours in the project calendar instead of
using availability. Can't give you a pro and con here - it's just that
I started this way and stuck to it. In my environment having 6.5h
instead of 8h seems to match reality best on average. Because this
"average overhead" isn't available for producing deliverables but paid
none the less, I have to adjust the cost rates by a factor of 8/6.5.

 

[Steve House]

I'm counter to the other two replies so far posted. It all hinges on what
you mean by 100% productivity. When you look at Joe's output, you look at
his track record and see that he produces 10 widgets per hour on the
average. But that already takes into account his occasionally going to the
bathroom, talking about the sports scores with his co-workers, handling
email and phone calls, etc. It's irrelevant that if he was totally focussed
on making widgets he could do 15 per hour - in the real world for as long as
you have records of his productivity he usually does 10. For all practical
purposes this represents 100% productivity for Joe. Now your task is to
make 250 widgets and you need to estimate how much time it will require -
250 widgets divided by 10 per hour means you need to allow 25 hours for Joe
to make those widgets. Duration equals 25 hours, assignment equals 100%.
Estimate duration based on known levels of productivity for the resources
you plan to assign and then assign them at 100%. The overhead allowance is
already built-in to the estimating process in the first place and can safely
be ignored.

 

[St Dilbert]

It all depends on the way your estimating process works - and as a
consequence the management culture in your project.
If you have known productivity levels, objective skills repositories I
can fully agree with Steve's recommendation - but it's a big IF in my
world...

The plans that come across my desk are not about making widgets or
anything else tangible - they mostly have deliverables like "design new
business process for dept XY", "update datamodel app YZ for new
business process", "develop migration strategy to new datamodel" etc...
now we had some goes in trying to introduce estimating methods like
CoCoMo II and failed miserably - maybe we're not mature enough, maybe
our projects and available resources really are too diverse to create a
reliable estimation metric - I just don't know. I've found nailing
Jell-O to the wall easy in comparison.

Here's how we get by: we do have a bottom up estimates for the
deliverables by the people delivering them later. We want them to
individually estimate the work for that. Sure we have sanity checks by
project management, but there still are variations of 100% and more in
estimates for deliverables that sound similar from the description. As
mentioned before we weren't successful in bringing those variations
down - after all we need the individual contributor to "own" both the
deliverable and the work estimate for it. When we tried narrowing the
variations in estimate we crossed the line to "arbitrary estimates
imposed by PM and I don't care anymore too often and too easily". So we
basically put in the work estimate after some basic sanity check and
that's it. On the other hand we don't want the individual contributor
to estimate the overhead and level of effort things like team
communication and "pad" them into the individual deliverable estimates
- calling just enough team meetings and keeping them efficient is
theproject manager's or team leads' responsibility - and they estimate
the "available productive time of work time" for the specific team
structure, project setup, "client difficulty" etc. and we're modeling
this practice in project with restricted calendars and increased cost
rates.

There definitely are more advanced (quantified) ways of estimating and
managing to those estimates even for our types of projects, but we
haven't been successful in implementing them. So far we've seen a very
significant improvement in predictability with little effort in trying
to get the practice accepted. The division of estimation responsibility
between individual contributor for "net work" and coordinating roles
for "overhead" works well even with frequently changing external
consultants/subcontractors.

Great discussion thread by the way - so many different ways to use
project "best" depending on what's available as input!

I'm counter to the other two replies so far posted. It all hinges on what
you mean by 100% productivity. When you look at Joe's output, you look at
his track record and see that he produces 10 widgets per hour on the
average. But that already takes into account his occasionally going to the
bathroom, talking about the sports scores with his co-workers, handling
email and phone calls, etc. It's irrelevant that if he was totally focussed
on making widgets he could do 15 per hour - in the real world for as long as
you have records of his productivity he usually does 10. For all practical
purposes this represents 100% productivity for Joe. Now your task is to
make 250 widgets and you need to estimate how much time it will require -
250 widgets divided by 10 per hour means you need to allow 25 hours for Joe
to make those widgets. Duration equals 25 hours, assignment equals 100%.
Estimate duration based on known levels of productivity for the resources
you plan to assign and then assign them at 100%. The overhead allowance is
already built-in to the estimating process in the first place and can safely
be ignored.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

I want to limit the amount of hours a resource is available per day for
almost every resource in my project file. As everyone knows we typically
do
not get a full 8hrs of productivity out each employees. Therefore I plan
to
put all resources at a max unites ranging from 90% to as low as 40% for
every
task they work on.

Does anyone have any feedback on the pros and cons of using this method?

 

[Steve House]

I use widget production because it's a nice tangible way to visualize the
process but it also applies equally well to the production of non-tangible
results. The point is that you have a definite and observable point where
the deliverable is done and it's going to take a specific amount of work to
get there, no more and no less. However you arrive at the estimates, when
you look back and say "it took us three weeks last year to re-engineer the
business processes for ABC department" and use that number to arrive at this
year's re-engineering of XYZ department, that 3 weeks you're using as input
data already includes an allowances for email, distractions, whatever else
the resource is doing in addition to the re-engineering task. If he was
only able to devote 3/4 of his time to the task, that 3 weeks represents the
time the task took at 6 hours per day on the task and 2 hours per day on
other stuff. Rather than try to break it out, just say that represents his
normal productivity and let a 100% assignment represent that rate of
progress. We really don't need to micromanage and account for the specific
activity in every minute of the his workday - all we really need to care
about is that when he is in his normal working mode, it will take him about
3 weeks to do that task.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

It all depends on the way your estimating process works - and as a
consequence the management culture in your project.
If you have known productivity levels, objective skills repositories I
can fully agree with Steve's recommendation - but it's a big IF in my
world...

The plans that come across my desk are not about making widgets or
anything else tangible - they mostly have deliverables like "design new
business process for dept XY", "update datamodel app YZ for new
business process", "develop migration strategy to new datamodel" etc...
now we had some goes in trying to introduce estimating methods like
CoCoMo II and failed miserably - maybe we're not mature enough, maybe
our projects and available resources really are too diverse to create a
reliable estimation metric - I just don't know. I've found nailing
Jell-O to the wall easy in comparison.

Here's how we get by: we do have a bottom up estimates for the
deliverables by the people delivering them later. We want them to
individually estimate the work for that. Sure we have sanity checks by
project management, but there still are variations of 100% and more in
estimates for deliverables that sound similar from the description. As
mentioned before we weren't successful in bringing those variations
down - after all we need the individual contributor to "own" both the
deliverable and the work estimate for it. When we tried narrowing the
variations in estimate we crossed the line to "arbitrary estimates
imposed by PM and I don't care anymore too often and too easily". So we
basically put in the work estimate after some basic sanity check and
that's it. On the other hand we don't want the individual contributor
to estimate the overhead and level of effort things like team
communication and "pad" them into the individual deliverable estimates
- calling just enough team meetings and keeping them efficient is
theproject manager's or team leads' responsibility - and they estimate
the "available productive time of work time" for the specific team
structure, project setup, "client difficulty" etc. and we're modeling
this practice in project with restricted calendars and increased cost
rates.

There definitely are more advanced (quantified) ways of estimating and
managing to those estimates even for our types of projects, but we
haven't been successful in implementing them. So far we've seen a very
significant improvement in predictability with little effort in trying
to get the practice accepted. The division of estimation responsibility
between individual contributor for "net work" and coordinating roles
for "overhead" works well even with frequently changing external
consultants/subcontractors.

Great discussion thread by the way - so many different ways to use
project "best" depending on what's available as input!

I'm counter to the other two replies so far posted. It all hinges on
what
you mean by 100% productivity. When you look at Joe's output, you look
at
his track record and see that he produces 10 widgets per hour on the
average. But that already takes into account his occasionally going to
the
bathroom, talking about the sports scores with his co-workers, handling
email and phone calls, etc. It's irrelevant that if he was totally
focussed
on making widgets he could do 15 per hour - in the real world for as long
as
you have records of his productivity he usually does 10. For all
practical
purposes this represents 100% productivity for Joe. Now your task is to
make 250 widgets and you need to estimate how much time it will require -
250 widgets divided by 10 per hour means you need to allow 25 hours for
Joe
to make those widgets. Duration equals 25 hours, assignment equals 100%.
Estimate duration based on known levels of productivity for the resources
you plan to assign and then assign them at 100%. The overhead allowance
is
already built-in to the estimating process in the first place and can
safely
be ignored.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

I want to limit the amount of hours a resource is available per day for
almost every resource in my project file. As everyone knows we
typically
do
not get a full 8hrs of productivity out each employees. Therefore I
plan
to
put all resources at a max unites ranging from 90% to as low as 40% for
every
task they work on.

Does anyone have any feedback on the pros and cons of using this
method?