Project is lying to me!

[Dan McCarty]

What did you input then?

I only entered the task description and work units (2 days). MSP
assigned it a start date of 11/30/04 (project start date) and a
duration of "0.84 days?". Later on I entered the % Done as 100%.

Looking at the task usage I see that MSP decided to help me finish the
project sooner by putting me down for "2d" of work on Tue, 11/30/2004.
Maybe that has something to do with why I'm allocated 870% that day...

Leveling at its finest, apparently.

 

[Dan McCarty]

Fixed Work, Fixed Units, or Fixed Duration doesn't mean that the specified
term is engraved in granite and will never change under any circumstances
nor does making something "fixed XX" mean that XX can't be edited. It only
means that the designated item is the constant term in the linear equation
W=D*U when doing something that changes one of the terms in the resource
assigments.

You understand that I know the difference between me making a change
to a fixed item and Project making an "behind my back" change to a
fixed item, right?

I guess I learn more about Project every day, a la the definitions
for "fixed" and "constant" have been redefined to mean "things that
might change under some circumstances." Maybe MSP should call them
"Usually fixed work," "Sometimes fixed units" and "Mostly fixed
duration."

Call me old fashioned, but when I say something is fixed, that means
that Project shouldn't change it. And when I say that something is a
constant in an equation it means that yes, actually, as far as Project
is concerned it IS engraved in granite and will NEVER change under ANY
circumstances.

I can post an example of a fixed-work task where the work units
actually change after another variable changes, contrary to everything
I've seen here and in the help. But so far the responses to the
examples that I've posted are on the order of "I don't doubt that your
example is legitimate, but you just don't understand MS Project."
(It's kind of like saying, "Yes, we know you have evidence that
exonerates you, but we think you don't understand our legal system so
you're still guilty.") So I don't know if posting another example will
add much value to this thread.

 

[Dan McCarty]

Project is very consistent in its behavior.

For those of you who believe that let me point you to this humorous
post:
http://groups-beta.google.com/group/microsoft.public.project/msg/4a4ca8e54222fbc9

On a serious note, I'm compiling a list of a few "inconsistent" things
I've found with MSP so far. I'll post them when I get a chance.

 

[Dan McCarty]

You might like to have a look at my series on Microsoft Project in the
TechTrax ezine, particularly #10 - Multiple Resource Assignments, at this
site: http://tinyurl.com/2xbhc or this:

http://pubs.logicalexpressions.com/Pub0009/LPMFrame.asp?CMD=ArticleSearch&AUTH=23

Very informative, thanks! And the tip about keeping the splitter
open when editing tasks with more than one resource is great. I found
that nearly all my tasks where resources were split--e.g.,
Dan[50%],Carl[50%]--actually had a mismatch of allocated work. For
example, on a 3-day task, MSP had assigned me (Dan) to 2+ days work and
Carl <1 day of work. Why? Idunno. I would say that it's another one
of those MSP inconsistencies, but I'm sure there are others here who
will quickly point out that it's because I don't understand Project.
Oh well, I'll lay off that one for a while... ;-)

Thanks again for the links.

-Dan

 

[Mike Glen]

You're welcome, Dan - stay in there buddy!

Mike Glen
MS Project MVP

You might like to have a look at my series on Microsoft Project in
the TechTrax ezine, particularly #10 - Multiple Resource Assignments, at this
site: http://tinyurl.com/2xbhc or this:

http://pubs.logicalexpressions.com/Pub0009/LPMFrame.asp?CMD=ArticleSearch&AUTH=23

Very informative, thanks! And the tip about keeping the splitter
open when editing tasks with more than one resource is great. I found
that nearly all my tasks where resources were split--e.g.,
Dan[50%],Carl[50%]--actually had a mismatch of allocated work. For
example, on a 3-day task, MSP had assigned me (Dan) to 2+ days work
and Carl <1 day of work. Why? Idunno. I would say that it's
another one of those MSP inconsistencies, but I'm sure there are
others here who will quickly point out that it's because I don't
understand Project. Oh well, I'll lay off that one for a while... ;-)

Thanks again for the links.

-Dan

 

[JackD]

For those of you who believe that let me point you to this humorous
post:
http://groups-beta.google.com/group/microsoft.public.project/msg/4a4ca8e54222fbc9

Here is the text:

"A few hours to get the basics. A week to learn all the features that it
has.
A month to make it work the way you want. A year to be able to figure out
why it doesn't work the way you want. Two years until you figure out how to
work around that."

Yeah, that was me. Sounds like you have about a year to go until you are a
believer too.

-Jack

 

[JulieD]

Hi Dan

i would be interested in your example ...

"> I can post an example of a fixed-work task where the work units

actually change after another variable changes, contrary to everything
I've seen here and in the help. But so far the responses to the
examples that I've posted are on the order of "I don't doubt that your
example is legitimate, but you just don't understand MS Project."

Cheers
JulieD

 

[Jan De Messemaeker]

Man, O man, anything we can look for but not leveling.
not leveling.
You must be using a product neither of us know.
As lond as you keep believing this is done by leveling there is no chance
whatsoever to undestand what really happened.

 

[Jan De Messemaeker]

That absolutely doesn't say it's not consistent.
It says it is complete and hence complex.

 

[Dan McCarty]

Man, O man, anything we can look for but not leveling.
not leveling.

Sorry, at this point I think I'm walking the fine line between
cheerful sarcasm and outright scorn. You'll have to forgive me if I
come off sounding too "scorny."

Thanks for all your help.

-Dan.

 

[Dan McCarty]

Hi Dan

i would be interested in your example ...

OK, here goes:
Task #162, Drawing problems with transparent bitmaps
Task type: Fixed Work
Constraint type: Start no earlier than 1/4/2005
Work: 2d
Start: 1/4/05
End: 1/5/05
% Complete: 100%
Duration: 1.4d?
Resource names: Dan[142%]

The last two are the most important. Project did that for me. I don't
know why Project calculates an estimated duration on a finished task.
The only thing I entered was the task desc., task type and constraint,
work and % complete.

So now I'll go to fix it:
1. Enter just "Dan" in the resource column to change the work units to
100%
2. Clear the duration column to let Project calculate it (instead of
1.4d).

At this point Project changes the duration to "1 day?", resets the
resource back to 142% and CHANGES the FIXED-WORK task to 1.43 days.

 

[JackD]

Hi Dan

i would be interested in your example ...

OK, here goes:
Task #162, Drawing problems with transparent bitmaps
Task type: Fixed Work
Constraint type: Start no earlier than 1/4/2005
Work: 2d
Start: 1/4/05
End: 1/5/05
% Complete: 100%
Duration: 1.4d?
Resource names: Dan[142%]

The last two are the most important. Project did that for me. I don't
know why Project calculates an estimated duration on a finished task.
The only thing I entered was the task desc., task type and constraint,
work and % complete.

How did the resource get there? I think you must have entered more than you
think...

So now I'll go to fix it:
1. Enter just "Dan" in the resource column to change the work units to
100%
2. Clear the duration column to let Project calculate it (instead of
1.4d).

At this point Project changes the duration to "1 day?", resets the
resource back to 142% and CHANGES the FIXED-WORK task to 1.43 days.

It is trying to maintain the actual work of two days (1.4142 * 1.4142 = 2.
The differences here -142% and 1.43 - are probably just display rounding).
Preservation of actual work is one of project's prime directives. Whenever
they blow it and screw with actual work EVERYONE yells at microsoft and
eventually they fix it.

You really shouldn't be changing tasks that are already finished. See what
happens when you set the task to 0% complete.

-Jack

 

[Dan McCarty]

How did the resource get there? I think you must have entered more than you
think...

You're right, I did enter "Dan" as the resource. (I just forgot to
mention that I did.) But I didn't enter "Dan[142%]".

You really shouldn't be changing tasks that are already finished. See what
happens when you set the task to 0% complete.

Well I wouldn't feel like I needed to change it if Project hadn't
overloaded the resource's work units on a finished task to begin with.
But the "0% complete" tricks works great. I can change the variables
back to how I want them without Project interfering, then mark the task
finished. Thanks again!

 

[JackD]

Well I wouldn't feel like I needed to change it if Project hadn't
overloaded the resource's work units on a finished task to begin with.

But the "0% complete" tricks works great. I can change the variables
back to how I want them without Project interfering, then mark the task
finished. Thanks again!

You are welcome. Poor little project was just trying to protect you from
your own mistakes and that is why the results weren't what you expected.
There is some irony in the fact that it was trying its hardest NOT to lie to
you.

They should include the following in the project help:

1) Ignore minor resource overloading. It happens in real life sometimes and
people just deal with it.
2) Don't mess with finished tasks.

-Jack

 

[JulieD]

Hi Dan / Jack

the only way i can get a resource to go over 100% when assigned "normally"
is to "play" with the hours ... ie i've defined a day as 10hrs, the
resource's calendar has a working day of 8hrs, so when i assign him to do 2
days of work (ie 20hrs - fixed work type task) Project initially assigns him
to work over a 3 day duration - if i then go into Resource / Task usage and
manually edit his hours to 10hrs per day - that's when the units "screw up"
.... i've never found that if my calendars are all in sync that i've ended up
with "minor resource overloading" ... am i just lucky or have i missed
something.

Cheers
JulieD

 

[Steve House [MVP]]

All things have meaning only in their specific contexts. The context for
task type says it only has meaning when you do something that changes the
values of work, units, or duration once resources have been assigned.
Setting the task to fixed work means that if you do something that changes
duration, units will be updated, or if you do something that changes units,
duration will be updated. There's nothing about it that says you can't
manually change the work on your own even after setting fixed work as the
task type, nor does setting the task type "fixed work" in and of itself tell
you what WILL get updated if you manually edit the work value of a fixed
work tasks (it's duration that'll change, by the way). Manually editing
units on a Fixed Units task also changes duration, while manually editing
duration on a fixed duration task will cause the work to be recalculated.

You understand that I know the difference between me making a change
to a fixed item and Project making an "behind my back" change to a
fixed item, right?

I guess I learn more about Project every day, a la the definitions
for "fixed" and "constant" have been redefined to mean "things that
might change under some circumstances." Maybe MSP should call them
"Usually fixed work," "Sometimes fixed units" and "Mostly fixed
duration."

Call me old fashioned, but when I say something is fixed, that means
that Project shouldn't change it. And when I say that something is a
constant in an equation it means that yes, actually, as far as Project
is concerned it IS engraved in granite and will NEVER change under ANY
circumstances.

I didn't say "you just don't understand project" I said to explain to you
what is happening we need to see the starting point before the problem you
describe manifested itself and then go step-by-step how you got from there
to the ending that illustrates the problem so that we can replicate it in
precisely the same way you encountered it. But saying you believe it is
resource leveling that is the culprit DOES show that as far as leveling is
concerned, you don't, in fact, understand what that part of Project actually
does. All leveling does is push work later in the schedule than it
otherwise would be scheduled so as to reduce a resource's instantaneous
total allocation to below the maximum allocation defined in the resource
sheet. It does not ever change the work, duration (for that resource -
because resources can be slipped separately the total duration of the task
might change due to resources no longer working together), or the percentage
the resource is assigned *on that specific task*. If the max is 100% and
the resource is assigned to 2 tasks at 100% each for a total of 200%,
leveling will delay one of them until it is clear of the other. If the
resource is assigned to *1* task at 150%, leveling will have no effect
because there is no way that could be reduced to 100% without changing
either the units or the duration and leveling doesn't do that. Simply
slipping the 150% task later from one day to the another doesn't resolve the
overbooking problem, it only changes the date on which it occurs.

 

[Steve House [MVP]]

I agree with Jack's post that you've cited 100%. Project works very
consistently with the way it was designed and the methodology it was
designed to follow. Even its quirks, and I'll freely admit it has a few, are
always quirky in a very consistent manner. If you get creative and want to
follow a different methodology you may get frustrated when it doesn't
readily adapt to your preferred style of working. But that's sort of like
saying you are more comfortable programming in C++ and are frustrated
because your C++ source code won't compile on the Visual Basic .NET compiler
<grin>.

 

[JackD]

When you mark a task as 100% complete and then change parameters (duration
etc.) on it, you do get some strange things happening.
As Dan has pointed out, the results are non-intuitive.
Best to avoid it.