On "fixed unit" task, changing units = recalculated WORK?

[aren]

POSITIVELY: if in your little test you introduce a work

column and fill in the work befoire assigning
the resource Project behaves the way you want.

That is one of the workarounds I already identified, and it has serious
drawbacks.

 

[aren]

Steve,

If your theory is correct, then Microsoft has made the very boneheaded
assumption that I know which resource I am going to assign to every
last task as I am creating the project plan. That assumption defeats a
big advantage of using a computerized project management tool: I should
be able to conceptualize a project without having to know exactly which
resource I will assign to every task.

In other words, I should be able to assign a resource with other than
100% availability after I have estimated task duration and expect my
project management tool not to put useless values in the Work field.
The only way you can defend this Project bug is to refute that
statement.

Here's a legitimate scenario: suppose I have a task that I know can
be performed by a pool of employees with similar skills and abilities
but different availability: employee A has 100%, employee B is 75%,
employee C is 50%. I enter this task and put 2 hours in the duration
field (complying with Microsoft's intent that I only enter values
into Duration and leave Work alone). Later, as I meet with the
employees' manager, we agree to assign employee C to that task. At
that point, Project creates a screwed up Work value of 1 hour once I
assign C to the task.

Project gives three key ways of assigning duration/work:
-Assign Duration but leave Work blank. This is how Microsoft expects
you to act since it only displays the Duration field on a blank new
project. As previously mentioned, Project creates a screwed up work
variable if you later assign a resource with an availability of other
than 100%.
-Assign Work but leave Duration blank. This is not what Project
expects. While Project fills in the Duration field with a good number
upon resource assignment, it puts a ? after this Duration value.
-Assign Work and Duration. This requires double entry and brings in the
various problems associated with double entry such as data concurrency
problems and increased maintenance requirements.

As I mentioned previously, Microsoft could have easily fixed this bug
with a two-step approach when the Work field has not previously been
modified from its default state:
1. Copy the Duration field value to the Work field.
2. THEN run the adjustment based on W=D*U.

In case I wasn't clear, yes, I understand that work is indeterminate
if it has never been filled in. I also understand that Project has to
make a guess as what to put in indeterminate Work fields. All I am
arguing is that because Project relys on a bad assumption, it puts bad
values in indeterminately-valued Work fields when I assign a resource
with other than 100% availability to a task with no current resource
assignment.

I do not wish to assign resources before I fill in the Duration field.
Is this not a legitimate method of creating a project? Because of
Project's bug/bad design, I am only left with unappealing workarounds.

 

[Jan De Messemaeker]

Hi,

YOu are absolutely right.
I don't understand what happened to that post.

In a nutshell:
When work is entered before a resource is assigned, when assigning the first
resource(s) Project will not change this Work Value.
If the task type is fiwed duratioon it will calculate units
When it is fixed units it will recalculate duration.

Isn't that what you want?
No lengthy workarounds, just remember that when in your view Work is
primordeal, you should insert teh column and enter it BEFORE assigning
resources.
And sorry for the misunderstanding - I'm absolutely sure I wrote this a few
days ago already but it must have gone lost.

Hope this helps,

 

[Jan De Messemaeker]

Drawbacks???

 

[aren]

Inserting a new Task is creation. Creating a new Resource is creation.

Changing a Resource field value from "indeterminate" or "unassigned"
to, say, "Resource A" is not creation. It is modification.

Resource is just presented as a field in a table. The Resource field is
created upon task row creation.

 

[aren]

Thanks for the suggestion.

Please try the example I posted in my earlier message (the one from
5:59 PM on April 12). It's a really quick test. You will see that
Project makes bad assumptions about what to do with the Work field
when:
1. Work field is indeterminate (I.e., you have never entered a value
into that field).
2. You are making an assignment to the Assignment field.
3. Assignment field was previously blank.
4. Assigned resource has an availability other than 100%.

What Project SHOULD do in this scenario:
1. Copy the Duration field value to Work field.
2. THEN and ONLY THEN run the W=D*R calculation to update D.

In other words, if no resource has ever been assigned and the Work
field is indeterminate, Project should just assume Work = Duration.

What Project actually does:
1. Assign a new value to the Work field using W=D*R. If you assign a
resource with availability other than 100%, you get a useless Work
value.
2. Leave you with a screwed up Work value because of bad assumptions
underlying step 1.

Remember that Project normally hides the Work field because it does not
intend for you to put values into the Work field under normal
circumstances. Therefore, step 1 under "What Project SHOULD do" is
reasonable for indeterminate Work fields under the scenario outlined
above.

 

[Steve House [Project MVP]]

You keep insisting this is a bug - it is not. A bug exists when the
software has a flaw so that it does not work as it is designed to do. That
is not the case here - Project is working exactly as it was intended and
exactly as is documented. It's had some bugs, but this ain't one of them.
You might disagree with the design philosophy but that's another issue
altogether. And yes, it does put the onus on you to think ahead to what
resources you will employ when you estimate the durations, but again, that's
just good PM practice anyway, regardless of what software you use or even IF
you use software - if I have to polish 100 widgets, whether I estimate based
on how long it will take or how many man-hours of effort it will require, I
should be thinking about whether I'm going to assign Joe who can do 5 an
hour or Bill who can do 20. And that sort of advance planning is needed
whether you're going to estimate durations or estimate man-hours.

Why does Project expect duration estimating with work being calculated as
the principle method? Well, just a guess on my part since I wasn't there
for the meeting <grin> but a very common approach in use is parametric
estimating - last year when we did a software rollout of 10 seats it took us
3 days so this year when we need to rollout 100 seats it will probably take
us 30 if we have similar resources available. We have historical data to
estmate duration but we very likely do not have as reliable a way of
estimating man-hours required. One of the problems with estimating work is
it's so hard to avoid the temptation to put the cart before the horse - we
can only afford to spend XX man-hours on this project so that's what we're
going plug in as the work estimate, conveniently overlooking consideration
of whether it's actually going to be physically possible to reach the
objective within XX man-hours. Duration can usually be estimated with
bottom-up thinking but work is all too often estimated by top-down
budgeting.

If you really want to use your method, start estimating in terms of work and
forget about entering duration. Add the work column to your Gantt chart
entry table. Enter the task name, leave the duration at its 1 day default
as you enter the new task, and enter the number of man-hours you estimate
for the work in the work column. When you assign the resource, set its
units to what you want them to be in the assignment dialog box and Project
will calculate the duration that would produce the input work at the
assignment percentage designated. What's so hard about that? It almost
appears that you are hung up on a desire to enter something into the
duration field and have Project assume that equates to full-time work hours
if it happens you haven't yet assigned resources. I'm afraid that just
isn't possible. If you want to estimate duration and have project calculate
work, enter duration and leave work blank. If you want to enter work and
have project calculate duration, leave duration at the default and manually
enter work before assigning the resources.

 

[Mike Glen]

Hi,

I'd like to add my observations to this interesting thread.

Firstly, the "?" that Project adds to Durations is simply an indication that
Project has made an estimation of the Duration, pending the agreement of the
Planner. Whether you agree or disagree with the estimate, just overtype the
value in the Duration column with what you what it to be and the ? will
disappear. Incidentally, if you want to enter a rough estimate, you can
also add the ? to indicate as such. The ? purely is a reminder to you (the
planner) that you need to firm up the Duration when you have that data.

As to the "bug" you report, I believe this is an arguable point and both
parties have valid comments. However, I would maintain that when you are
planning the tasks and their sequence, you should not consider which
resources will be allocated or their availability. The network should
assume infinite resources to maintain the purity of the logic and allow
maximum flexibility (logic should not be dictated by resource availability).
Thus, you assume 100% availability of all resources.

Now, when you come to assign resources, you can do so easily with all those
with 100% availability as you have assumed in your planning, and Project
recognises that. What Project cannot do is assume that anything less than
100% will apply or to what level. So, if you have to assign resources that
are not available 100% you will have to calculate the effect of this on the
Duration of the task at the time you make the assignment. That is why
you're getting the effect you see. Project is designed that way, and none
of us has access to the minds that created it, nor can we change the design
(oh that we could!!!).

Mike Glen
MS Project MVP
See http://tinyurl.com/2xbhc for Project Tutorials

 

[novasource]

First, Wikipedia's definition of "software bug"
(http://en.wikipedia.org/wiki/Software_bug) fully includes this
problem, which is a "flaw" that "produces an incorrect result."

This is a bug.

... it does put the onus on you to think ahead
to what resources you will employ when you estimate
the durations, but again, that's just good PM
practice anyway

I agree in general. However, it's not reasonable to say that the PM
always knows exactly who will be assigned to each task (and hence the
expected availability) as he is fleshing out the project. It is
perfectly normal and rational to have a pool of potential workers from
which you can choose a "best fit" for the project, especially in an
environment where the project is a long way from actually executing or
in a fast-paced environment where employee availability aren't always
known well in advance. Or how about simple informal settings where
teams are assembled as the project evolves?

Suppose "The Project" includes task A. Further suppose "The Project"
will be executed 2 months from now, and at the present time it is not
clear which employee will be assigned to this project? If you support
MS Project's bug, you are punishing this PM.

Here's yet another example: suppose a resource has different levels of
availability over the course of a project. Does the PM have to keep
track of this while he's assigning task durations? Certainly not!

Why punish this PM just for the sake of a faulty algorithm?

In fact, isn't one of the premises of Project that the PM DOES'T have
to worry about DOESN'T have to worry about resource availability? I.e.,
the tool will take care of it for you? If that's not the case, why is
the feature even present?

If you are going to argue that the PM has to estimate duration based on
resource availability, you are making the PM's job much harder just so
the software can refuse to handle a simple mathematical calcualtion. Is
that defensible to a rational person?

All the PM should have to do is answer this question on each task: "How
many hours would this take if I had uninterrupted labor assigned to
this task?" That's it. Project is supposed to take care of the rest for
you. Unfortunately, Project screws this up in the scenario that started
this thread.

We have historical data to estmate duration but
we very likely do not have as reliable a way of
estimating man-hours required.

Nice example but it doesn't address my issue. You're talking about how
to establish an initial time estimate. I am talking about how Project
FUBARs the Work field associated with my initial estimate.

Enter the task name, leave the duration at its 1
day default as you enter the new task, and enter
the number of man-hours you estimate for the work
in the work column. When you assign the resource,
set its units to what you want them to be in the
assignment dialog box and Project will calculate
the duration that would produce the input work at
the assignment percentage designated. What's so
hard about that?

I agree that it's easy. It would be nice if it worked. The problem is
that is not how Microsoft intended for me to use the product. Try that
example I gave in the post dated 4-12-06 5:59 PM. You'll see that if
you enter Work but leave Duration untouched, when you assign the first
resource, Project does indeed put a valid value into Duration, but it
trails it with a ? symbol. This means it's an "estimated duration"
(http://tinyurl.com/p2hnp), and my prior experience is that using
estimated durations leads to other problems and triggers unnecessary
warnings. Is that not correct?

And why is it estimated? It it no longer the case that W=D*R? If you
know W and R, then you can calculate D. How is D an estimate in this
case, but it wouldn't be an estimate in this case:
1. Create a new task.
2. Enter 1 hour for Work and Duration.
3. Assign a resource.
4. Enter a different Work value.

Viola! You have a new Duration, and it's not an estimate!

And why is it that when Project screws up the Work field in the bug I
pointed out, that new Work value is not an estimate?

See the logical flaws?

Microsoft's intent is clearly for me to enter an initial value into the
Duration field and leave the Work field alone. That's why the Work
field is initially hidden, and that's why the Duration field becomes an
"estimated duration" if you're not careful. I don't like using
Microsoft software against the intended use becuase that often leads to
problems. (Note that I am not a Microsoft hater. Microsoft software
almost always anticipates reasonable usage patterns; this is a big
exception.)

I am not sure this merits any further discussion except to alert
Microsoft of this bug. I'll restate the simple solution:

IF a project has these properties:
1. No current assignment.
2. No current value for Work.
3. A valid value for Duration.
THEN upon the first resource assignment, Project should FIRST set Work
equal to Duration AND ONLY THEN should use W=D*R to update D (and NOT
change W).

 

[novasource]

Whether you agree or disagree with the estimate, just

overtype the value in the Duration column with what
you what it to be and the ? will disappear.

I wish that wasn't the only option. That is an invitation for errors,
typos, and data concurrency issues.

The ? purely is a reminder to you (the planner) that you
need to firm up the Duration when you have that data.

Hmmm, so it has no other ill effects? I recall other problems related
to the ? on a previous project, but I cannot remember them offhand
right now. That would really be great if the ? is really innocuous.

The network should assume infinite resources to maintain
the purity of the logic and allow maximum flexibility
(logic should not be dictated by resource availability).
Thus, you assume 100% availability of all resources.

I agree 100%. When I type in the Duration, I am assuming that I have
100% resource availability, so the resulting Work value should equal
that duration.

Project is designed that way, and none of us has access to the
minds that created it, nor can we change the design
(oh that we could!!!).

Heh.

I've probably spent too much time on this thread already. I need to
do some actual work. Thanks for the thoughts.

 

[Jan De Messemaeker]

Hi,

As I explained somewhere else, I rather not read what Project should do in
your opinion.
Making a software is a matter of choices and who says my choices are better
than yours or theirs?

The most you can say is xhat I would like Proect to do...

And when I recommend you to enter work before assigning, I am astonished to
read an answer debating on Project's reaction to NOT entering work.
If you don(t like Project's formulas when asigning at work 0, do enter the
work before assigning.
There is no more than that.
HTH

 

[Jan De Messemaeker]

But you create an asignment; that is creation of an object as well. It is
shown in a cell in task or resources views, but it is a new object.

 

[Mike Glen]

Hi,

The ? is innocuous see Help:

An estimated duration (estimated duration: A duration for which you have
only enough information to determine a tentative value. So that its status
is clearly visible, an estimated duration is clearly marked by a question
mark immediately following the duration unit.) is a current best guess at
how long you believe a task (task: An activity that has a beginning and an
end. Project plans are made up of tasks.) will take to complete. When a
duration is flagged as an estimate by using the question mark, this
indicates there is still information pending, usually from the resources who
will be responsible for the task. The uncertainty in an estimated duration
contributes to the uncertainty in the project end date, which means that the
end date might be at risk (risk: An event or situation that may negatively
affect project scope, schedule, budget, or quality.). You can view all tasks
with estimated durations. You can then determine which estimates are still
accurate and which should be updated.

Hmmm, so it has no other ill effects? I recall other problems related
to the ? on a previous project, but I cannot remember them offhand
right now. That would really be great if the ? is really innocuous.
=============
I agree 100%. When I type in the Duration, I am assuming that I have
100% resource availability, so the resulting Work value should equal
that duration.

Nope. When you type in Duration, there is no assignment made, so Work is
still zero. It's only when you assign a resource that a Work value is
entered, either by an unintilligent Project or by you using your
intelligence.
===========

I've probably spent too much time on this thread already. I need to
do some actual work. Thanks for the thoughts.

You're welcome Me too!

 

[aren]

An assignment is a relation between a task and a resource. A relation
is not necessarily an object. Now, there could be a third table
managing the many-to-many relationship between tasks and resources, so
theoretically a new row could be added to that table with the
assignment of each resource to a task. However, I don't see that as
object creation in and of itself. It's more of a utility function.

 

[Steve House [Project MVP]]

....

....>
And why is it estimated? It it no longer the case that W=D*R? If you
know W and R, then you can calculate D. How is D an estimate in this
case, but it wouldn't be an estimate in this case:
1. Create a new task.
2. Enter 1 hour for Work and Duration.
3. Assign a resource.
4. Enter a different Work value.

Viola! You have a new Duration, and it's not an estimate!

Actually it is an estimate. Anything you put into the plan is a guess until
you actually go out and complete the work. So in your above example, you
are estimating the work required and Project is giving you a corresponding
estimate of the time required to do that work. But neither one of them is
engraved in granite, absolutely guaranteed to be what will actually be done
in the project when the resource picks up his tools and actually creates the
task's deliverable.

 

[aren]

Actually it is an estimate.

OK, I grant you that. But there are "estimates," and then ther are
"estimates followed by a question mark." E.g., "2d" vs "2d?". What's
the difference?

In the above example, I have an estimate, but it's not followed by a
question mark.

 

[Jan De Messemaeker]

Learn some VBA you'll know what Project's objects are.
An assignment is an object in Project.

 

[Steve House [Project MVP]]

As Mike pointed out, the question mark doesn't really have any function
within the software. I think of it as a reminder note to myself that I have
entered the task in the list but I haven't visited the questions of work and
duration associated with it. When it gets down near time to finalize the
plan I might filter the task list for tasks with estimated durations just to
make sure I've got my "t"s cossed and "i"s dotted and nothing has fallen
through the cracks. But aside from that, it has no use and no impact.