Task Type Differences

[CJ]

Hi, I'm a bit of a Project newbie.

I can not get my head around the difference between a "fixed unit task" and
a "fixed work task". It seems to me that adding resources to both will
accomplish the same result. I have been unable to find an example of fixed
work that will help me to understand it better.

Can somebody please respond with an example of each and why it makes a
difference?

Thanks.
CJ

 

[JackD]

Project uses the formula Work = Units * Duration
In this formula Units refers to resources.

If you fix the Work then adding resources will proportionately decrease the
duration. It won't change the Work.

If you Fix the Units, then adding resources means that you are overriding
the fixed units. What project does in this case is uncertain as you have two
variables.
Normally you would fix the units and then vary work or duration.

If you fix the duration then adding resources will increase the work. It
won't change the duration.

 

[CJ]

Hi Jack, thanks for your response.

I understand the formula involved, but I guess I still don't see why or when
you would ever need to use a Fixed Work task. It is effort driven anyway so
why worry with it?

Do you have an example you could use?

Thanks

 

[JackD]

I'd used fixed work if there was a known about of work to be done and I
wanted to know how long it would take to do it if I changed my resource
allocation. Or if I wanted to shorten the duration and know how many people
I need to do the work.
Being effort driven doesn't really make the difference you think it does.

 

[CJ]

OK, but wouldn't you still get the same results by making the tasks Fixed
Unit and Effort Driven?

For example:

I set up the same task in 2 different ways. Both tasks have 1 resource
assigned (100%) and takes a total of 6 days (48hrs). The first task is Fixed
Unit, Effort Driven the second task is Fixed Work, Effort Driven. If I add
an additional resource to each of them I get the same results for the
tasks...2 resources at 100%, 3 days, 24h each.

So I guess the question is "What have I learned that is different between
the two?" The resources need to do the same amount of work over the same
time period. So what is the benefit (or repercussions) of one method over
the other?

Maybe I am completely missing the boat.................

 

[JackD]

Effort driven only applies when you add multiple resources, not when you
adjust the percentage on a single resource. Treat it as a special case.
Also, in the case of the fixed units task you are overriding the units so
you can't really consider it a fixed unit task if you are changing the
units. Make a change to duration in both of these cases and see what
happens.

 

[CJ]

...............and then the blind shall see!!!!

OK!! So, I changed the duration for both tasks to 4 days. In the first task
(Fixed units) each resource is still at 100% for 32h each. In the second
task (Fixed work) each resource is only at 75% for 24hr each. Now that I see
a different result, I can figure it out.

Therefore, my thought is that Fixed Work is only for special cases (as you
mentioned). I still can't think of a practical example of when I would use
it but at least I understand it better.

Thanks Jack.

 

[JackD]

I use fixed work all the time. It is useful when you need to determine the
number of resources needed to meet your schedule.

 

[John Sitka]

I still can't think of a practical example of when I would use it but at least I understand it better.

That's interesting CJ because I see fixed work as the most practical task type.
To me it is the most basic.
Work = Units * Duration
If you can see the benefits that resources will behave in a focused manner
and their units will default to 100% building a plan and tracking the progress becomes
a trivial iteration of breaking down a project into discrete packets of "named" work
and ordering those in some logical sense. Most of the world does not understand that they are NOT working
on five things at once. However much they claim they are, it is just BS to remove accountablity for their actions.
We all behave like this is a truth but it isn't, no shame in that it's just the way people think about how the do stuuf.
So dismiss this notion and take as another truth that there is no way to represent it in Project. Why is this important?
because we want to simplify we have just made units 1 "always" in every case. Of course there is resistence to
this. This newsgroup is evidence that there is an industry built around a productivity measure of units, it has it's own
momentum, but it's just a thought model, not wrong or right, but not the only one.

If work goes up you need more time.
I can't see any benefit to a units change other than as a multiple of 1.
Say for example 10 hours work needs to get done in 5 hours, UNITS goes to 200%
because you need to "half" the time to meet a deadline you apply another full resource.
The plan is correct at that point. but without tracking it is only a guess as to what is really going to happen.
The two resources may actually contribute different percentages to the completion
of the whole task (ex.Resource 1 authors 800 lines of code and Resource 2 authors 200)
lines of code but that measure is meaningless to task accomplishment. As the task measure
we are concerned about is time not skill. Effeciency or productivity is a conceptual gauge for the
estimate; a local variable, but not a goal of the Project. What if the application of the 2nd resource
allowed Resource 2 to shave the time in half because of a "good suggestion" to the 1st
There is no effeciency measure for that. The task report is that Resource 2 gets returned to the pool
and Resource 1 tells you immediately that it will only take him 5 hours after a 15 minute consultation with
Resource 2.

 

[John Sitka]

Oops forgot one thing....
Consider this...
"Tracking is more important than the sun rising."

To base the progress of a project on the fact that the passage of time occurs might not be the best way to
think of things. After all some of us have been known to not make any progress after a long period of residency
n a certain task that was estimated to be a rather quick one. If that progress is measured by time and the default
condition of time passing is work got done, that's a huge assumption. Not really related to fixed work and/or fixed units
but it is part of the approach since work is tracked, I can't see how any Project is an accurate schedule without tracking.
It becomes a reactive entity rather than a dynamic proactive one.

 

[CJ]

And then I had so much more to think about.

You bring up some good points John. There is always so much more to consider
than what "the product" produces.

Thanks for your input................proves the benefits of newsgroups once
again.

CJ

 

[Steve House [Project MVP]]

Fixed work is probably the most common case, actually. Think of it this
way. A Task by definition always requires the production of a finite,
quantifiable, observable output - I have 100 widgets to polish or 100 square
feet of wall to paint or 100 cubic yards of dirt to remove from a hole or
100 pages of contract to review. "Work" is a measure of the energy required
to accomplish that result. We can move the dirt fast or we can move it
slowly but moving 1 cubic yard of dirt 10 feet requires exactly the same
amount of energy regardless of the speed we move it. The hole requires 100
cubic yards be moved, no more and no less, and so the total *amount* of
energy spent in moving it will be exactly the same regardless of how long we
take. A resource working at 100% applies energy to the task at a specific
fixed rate - our painter can paint 10 square feet per hour working at
maximum speed. When he works at 50% he expends energy at half that rate and
paints 5 square feet per hour. The work required to paint 100 square feet
is constant but the time required to paint that wall will depend on what
percetnage of his maximum possible rate the painter actually paints.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



......>