Issues with Fixed Duration tasks...

[fowlemr]

In MS Project 2003 I have a task with two resources. The task type is
defined as Fixed Duration, NON effort driven.

The problem we have is adding ACTUAL work to a resource who has
exhaused what we "estimated" him/her to work. For example...

On a 10 day task, Tim and Joe have both estimated that it will take
them 8 hours each to paint a room. On day 5, Joe has worked all of his
estimated 8 hours, and Tim has only worked 4 thus far. Well...Joe has
some extra capacity, so on day 6 we want to ADD more ACTUAL work (an
additioinal 4 hours...12 total), however, when we do so, Fixed Duration
changes. It's only day 6 of a 10 day task, yet Project changes FIXED
DURATION to 15 days.

Ideas? =)

 

[John]

In MS Project 2003 I have a task with two resources. The task type is
defined as Fixed Duration, NON effort driven.

The problem we have is adding ACTUAL work to a resource who has
exhaused what we "estimated" him/her to work. For example...

On a 10 day task, Tim and Joe have both estimated that it will take
them 8 hours each to paint a room. On day 5, Joe has worked all of his
estimated 8 hours, and Tim has only worked 4 thus far. Well...Joe has
some extra capacity, so on day 6 we want to ADD more ACTUAL work (an
additioinal 4 hours...12 total), however, when we do so, Fixed Duration
changes. It's only day 6 of a 10 day task, yet Project changes FIXED
DURATION to 15 days.

Ideas? =)

fowlemr,
Are you sure the task is truly Fixed Duration, non-effort driven? I
tried your scenario. When I added 4 hours of Actual Work for Joe on day
6, duration stays at 10 days and Joe's work increases to 12 hours.

Just for reference here is how I set it up (Project 2003 Pro but Project
2003 Standard will work the same).
1. Create a task called Paint Room
2. Go to Project/Task Information/Advanced tab and set the Task Type for
"Fixed Duration", non-effort driven.
3. Set the Duration field at 10 days
4. In the Tools/Assign Resources window I Assigned Joe at 8h (10%) and
Tim at 8h (10%). The task shows 26h of scheduled work.
5. Then I opened the Task Usage view to chart their progress. For
convenience I gave Joe 2h, 2h, 2h, 1h and 1h respectively of Actual Work
for the first 5 days. I gave Tim 1h, 1h, 1h, .5h, .5h respectively of
Actual Work. At that point, Joe's work is complete but the task still
has 5 days of .8h each for Tim, or 4 hours left on the task.
6. Finally I gave Joe 4h on day 6. His total work increased to 12h and
the total work for the task increased to 20h. The task duration remained
at 10 days.

John
Project MVP

 

[fowlemr]

Hi John, and thanks for the reply!

You've hit on part two of my issue! Everything up to step #5 is
exactly how we have our scenario defined. However, in step #5 try
putting ACTUAL work in the Task Form view. The reason I suggest this
is because we use EPK to progress our actual work effort to Project
Pro. The "powers that be" tell us that MSP brings these ACTUAL work
values over much the same way as one would input time in the Task Form
View.

You are right...if I use the Task Usage View or even the Resource Usage
View, everything works as it should. So, besides my original question,
why isn't ACTUAL work treated the same in all the views?

You can imagine a 200+ line project where each task has dependencies,
and the project is slated to last around 18 months. When we allocate
more ACTUAL work effort to a task, by a resource, it has thrown project
completion dates out to 2038!!! We have 32 projects opened today and
80% are experiencing this issue. Perhaps Fixed Duration, Non-effort
driven task types aren't the way to go? What do best practices
suggest?

Thanks again for your help. I hope I was able to clarify our problem.

 

[davegb]

Hi John, and thanks for the reply!

You've hit on part two of my issue! Everything up to step #5 is
exactly how we have our scenario defined. However, in step #5 try
putting ACTUAL work in the Task Form view. The reason I suggest this
is because we use EPK to progress our actual work effort to Project
Pro. The "powers that be" tell us that MSP brings these ACTUAL work
values over much the same way as one would input time in the Task Form
View.

You are right...if I use the Task Usage View or even the Resource Usage
View, everything works as it should. So, besides my original question,
why isn't ACTUAL work treated the same in all the views?

This is a common problem in Project. You don't always get the same
results when you enter the same data into the (apparently) same field
in a different table or form. This is particularly evident when
entering data in a form vs. in a table.

To avoid this problem, I write "Protocols" for my clients. Once we've
established procedures to get the results they want, I write them up
and they become a standard Protocol for doing that particular thing.
There are often several Protocols for different situations. These are
particularly useful when assigning Resources to tasks and work to those
resources. For each different desired result, there is a specific
protocol which must always be followed.

This is one of a number of reasons why I encourage my clients to
minimize the number of users who actually enter data into their
schedules. Only people who've been thoroughly trained and who can be
trusted to follow the protocols are allowed direct access to the
schedule.

You can imagine a 200+ line project where each task has dependencies,
and the project is slated to last around 18 months. When we allocate
more ACTUAL work effort to a task, by a resource, it has thrown project
completion dates out to 2038!!! We have 32 projects opened today and
80% are experiencing this issue. Perhaps Fixed Duration, Non-effort
driven task types aren't the way to go? What do best practices
suggest?

Figure out what works for you in any given situation, then document the
protocol to be followed in that situation.


Hope this helps in your world.

 

[John]

Hi John, and thanks for the reply!

You've hit on part two of my issue! Everything up to step #5 is
exactly how we have our scenario defined. However, in step #5 try
putting ACTUAL work in the Task Form view. The reason I suggest this
is because we use EPK to progress our actual work effort to Project
Pro. The "powers that be" tell us that MSP brings these ACTUAL work
values over much the same way as one would input time in the Task Form
View.

You are right...if I use the Task Usage View or even the Resource Usage
View, everything works as it should. So, besides my original question,
why isn't ACTUAL work treated the same in all the views?

You can imagine a 200+ line project where each task has dependencies,
and the project is slated to last around 18 months. When we allocate
more ACTUAL work effort to a task, by a resource, it has thrown project
completion dates out to 2038!!! We have 32 projects opened today and
80% are experiencing this issue. Perhaps Fixed Duration, Non-effort
driven task types aren't the way to go? What do best practices
suggest?

Thanks again for your help. I hope I was able to clarify our problem.

fowlemr,
Yes you did clarify your issue and that's why I included my exact steps.
However, I see that Dave has already provided an excellent response so
there isn't a whole lot I can add.

My only added comments are the following. At the company where I worked,
we also used fixed duration task types. That is because our earned value
and financial interface was not done with Project but with MPM. I think
most of my fellow MVPs would agree that generally, fixed duration is
probably not the best way to go since it isn't really natural. That is,
duration doesn't accomplish anything, (except in a few cases like LOE
tasks), rather, work is the driving force behind progress, although it
is interesting that the default task type for Project is Fixed Units.

John
Project MVP

 

[Steve House]

My question back to you is how could changing estimated work or posting an
Actual Work that is different for the originally Estimated Work (the plain
vanilla Work field) be expected NOT to change duration? A task is expected
to require 40 man-hours of work to complete. We assign Joe at 100% and so
the duration of the task is also 40 hours. Once he does the task however we
find he actually has to 60 man-hours of work to complete it. Note that it's
physically impossible for any one individual to ever work at more than
100% - there's no way 1 person can accomplish 2 man-hours of work during 1
hour of working time, for example - and so it will have taken Joe at least
60 hours of duration time to complete his 60 man-hours of work. Otherwise
we'd have one man doing 60 man-hours of work in 40 hours of duration and
that's simply not possible.

 

[Steve House]

If I can interject - I think the default is fixed units because units is a
measure of the rate at which people work and most people work at a pretty
constant pace. So if we're trying to model natural behaviour, saying
someone is working at 50% initially but when we change the estimate of the
amount of work performed the resource will "ramp-up" his working pace so
he's now at 75% so that the duration doesn't change. Similarly as I point
out in my other post in this thread, it is physically impossible for anyone
to ever work at more than 100% so a having the normal behaviour be that
when the work estimate is increased on a task where the resource has been
assigned 100%, the task duration is held constant and the effort units are
increased to something over 100% just doesn't make any sense at all. Since
the rate at which Joe converts time into task output is pretty well fixed in
granite by a combination of Joe's personal attritbutes and the physical
nature of the work itself, to have units fixed so that work estimates will
drive duration and/or duration estimates will drive work seems to me to be
the most accurate way to model physical performance.

I think one problem is the myth (IMHO) that you can budget and ASSIGN work
to a task. You can't. You can only discover how much work will be
required. If the task is to produce 100 widgets, the work required is fixed
by the nature of the widget construction process. It will take a precise
amount of work to produce them, no more and no less. You can't decide how
much work to allocate to widget production, only discover how much work is
going to be required to produce the number of widgets you need. You get to
choose the number of widgets to produce but once you've made that decision
the amount of work expended to produce them is fixed. The trick for the PM
is to know what it is.

 

[John]

If I can interject - I think the default is fixed units because units is a
measure of the rate at which people work and most people work at a pretty
constant pace. So if we're trying to model natural behaviour, saying
someone is working at 50% initially but when we change the estimate of the
amount of work performed the resource will "ramp-up" his working pace so
he's now at 75% so that the duration doesn't change. Similarly as I point
out in my other post in this thread, it is physically impossible for anyone
to ever work at more than 100% so a having the normal behaviour be that
when the work estimate is increased on a task where the resource has been
assigned 100%, the task duration is held constant and the effort units are
increased to something over 100% just doesn't make any sense at all. Since
the rate at which Joe converts time into task output is pretty well fixed in
granite by a combination of Joe's personal attritbutes and the physical
nature of the work itself, to have units fixed so that work estimates will
drive duration and/or duration estimates will drive work seems to me to be
the most accurate way to model physical performance.

I think one problem is the myth (IMHO) that you can budget and ASSIGN work
to a task. You can't. You can only discover how much work will be
required. If the task is to produce 100 widgets, the work required is fixed
by the nature of the widget construction process. It will take a precise
amount of work to produce them, no more and no less. You can't decide how
much work to allocate to widget production, only discover how much work is
going to be required to produce the number of widgets you need. You get to
choose the number of widgets to produce but once you've made that decision
the amount of work expended to produce them is fixed. The trick for the PM
is to know what it is.

Steve,
First I am not going to disagree with what you are saying but I will
make a few comments..... so maybe that does mean I disagree in a few
areas.

I take issue with the idea that a resource cannot "ramp-up". If you are
talking in terms of a resource's efficiency then yes, it is difficult,
(but not necessarily impossible), to make a resource more efficient.
However, let's say a resource is assigned at 50% (i.e. half time) but
the task just isn't getting done. I am his supervisor and I recognize
that he needs to spend more time on the task so I up his assignment to
75% (i.e. more than half time). And yes, that probably means I have to
take him off of some other task to increase his availability but this
type of resource management is done every day. My point here is that
resource units are NOT all that cast in concrete.

Next let me poke at another seemingly fixed parameter, namely 100%
allocation. Let's say we have a resource assigned to a task at 100%. The
task is estimated at 40 hours so work and duration are both 40 hours.
After starting the task we realize it is going to take closer to 60
hours to complete. Can the duration stay at 40 hours with only one
resource? Sure, and it isn't all that difficult. Have the resource work
overtime. Based on a standard 8 hour work day won't that resource now be
at greater than 100%? Maybe not so "physically impossible".

On the subject of widget production. Anyone who has ever been involved
in a production environment knows that nothing is certain. Things go
wrong. Raw materials aren't available. A process goes out of control. A
machine breaks down. Whatever. So the work to produce any quantity of
widgets is not fixed. However I do agree that work assigned to any task
is only an estimate based on historical data or experience and that the
true value will not be known until the task is complete. I think the
concept of "budgeting" work is better explained in the realm of labor
effort rather than for production of something. It took me several
"reads" of your last paragraph to understand your first sentence about
budgeting and assigning work - at least I think I understand what you
were trying to say. Let's try this example instead. An engineer
estimates that it will take 320 hours to design an amplifier. He bases
his estimate on historical data and/or experience. His management on the
other hand decides that the project can't "afford" that amount of time
for amplifier design so he arbitrarily scales back the design estimate
to 200 hours. The manager has in effect attempted to "budget" work
content that the engineer knows is not adequate. It MAY be possible to
do the work in 200 hours but the sensible approach would be to assign
the engineer his 320 hours. If the actual work comes in at 200 hours
then great, but 200 hours should not be the budget. Did I hit the nail
more squarely or did I only put a dent in the wood?

John

 

[Steve House]

Steve,
First I am not going to disagree with what you are saying but I will
make a few comments..... so maybe that does mean I disagree in a few
areas.

I take issue with the idea that a resource cannot "ramp-up". If you are
talking in terms of a resource's efficiency then yes, it is difficult,
(but not necessarily impossible), to make a resource more efficient.
However, let's say a resource is assigned at 50% (i.e. half time) but
the task just isn't getting done. I am his supervisor and I recognize
that he needs to spend more time on the task so I up his assignment to
75% (i.e. more than half time). And yes, that probably means I have to
take him off of some other task to increase his availability but this
type of resource management is done every day. My point here is that
resource units are NOT all that cast in concrete.

Next let me poke at another seemingly fixed parameter, namely 100%
allocation. Let's say we have a resource assigned to a task at 100%. The
task is estimated at 40 hours so work and duration are both 40 hours.
After starting the task we realize it is going to take closer to 60
hours to complete. Can the duration stay at 40 hours with only one
resource? Sure, and it isn't all that difficult. Have the resource work
overtime. Based on a standard 8 hour work day won't that resource now be
at greater than 100%? Maybe not so "physically impossible".

I think of overtime as work outside of the clock and, just like the notion
that W=D*U for each of 2 resources on a task is computed independently, for
a single resource standard-time work and overtime work are also computed
separately. I think of the units number as indicating the RATE at which
time is converted to useful work ouput. 100% means that he generates 1 hour
of work output for each hour of time he puts in. 50% means he generates the
equivalent of 1/2 hour of FTE work for each hour he spends, certainly a
possible state of affairs if he has to divide his attention between the task
at hand and other stuff. But there is no way he can spend one hour of
physical time making some super-human effort and generate the amount of
output that would normally take him two hours to do. Thus a resource with
an 8-hour a day calendar who works 12-hours on a particular day is not
working at 150%, he is working 8 regular hours @ 100% plus 4 overtime hours
@ 100%, of which only the 8 regular hours are counted in the duration
numbers (but all are counted in the budget numbers). Only work on standard
time counts towards duration but work on both standard time and overtime
count towards elapsed time. But I will say this as well, IMO there's really
no perfect way to treat it, only a matter of which way produces the least
inaccurate model.

On the subject of widget production. Anyone who has ever been involved
in a production environment knows that nothing is certain. Things go
wrong. Raw materials aren't available. A process goes out of control. A
machine breaks down. Whatever. So the work to produce any quantity of
widgets is not fixed. However I do agree that work assigned to any task
is only an estimate based on historical data or experience and that the
true value will not be known until the task is complete. I think the
concept of "budgeting" work is better explained in the realm of labor
effort rather than for production of something. It took me several
"reads" of your last paragraph to understand your first sentence about
budgeting and assigning work - at least I think I understand what you
were trying to say. Let's try this example instead. An engineer
estimates that it will take 320 hours to design an amplifier. He bases
his estimate on historical data and/or experience. His management on the
other hand decides that the project can't "afford" that amount of time
for amplifier design so he arbitrarily scales back the design estimate
to 200 hours. The manager has in effect attempted to "budget" work
content that the engineer knows is not adequate. It MAY be possible to
do the work in 200 hours but the sensible approach would be to assign
the engineer his 320 hours. If the actual work comes in at 200 hours
then great, but 200 hours should not be the budget. Did I hit the nail
more squarely or did I only put a dent in the wood?

John

Exactly! One of the great self-delusions a manager can have is the idea
that he can arbitrarily decide how many many-hours he can afford to spend in
accomplishing a goal and then somehow motivate the resources to get all the
required output created within that allocated work budget. It don't work
that way - the amount of work that will be required to achieve a stated end
result is driven mostly by what I think of as the "physics of the task" and
is not influenced very much by management's desire or the availability of
assets.