Estimated duration question marks

[Sandie K]

Is there a way to make question marks disappear automatically when you enter
WORK (not duration) for an estimated task? I do not want to eliminate the
function because I want to know if there are outstanding estimated tasks, but
I don't want to have to retype the duration after I've entered work and
clicked "OK".

I guess the bottom line is: is the "estimated duration" function driven only
by duration, not by work? (This would indicate a prejudice against those of
us who frequently ask the tool to arrive at duration based on WORK estimates
rather than duration estimates.) What good is the Fixed Work option if you
are still forced to manually type in duration?

Thanks!

 

[Andrew Lavinsky]

You can toggle that functionality on and off through Tools > Options > Schedule

"Show that tasks have estimated durations."

And yeah, if you change work, it will still show the duration as estimated
until someone goes in and enters duration. Technically speaking, even if
you're calculating with work, it's still estimated.

-A

 

[Sandie K]

Hi Andrew
I already know about the the toggle--that's why I said I do not want to
eliminate the function.

As far as I can see, this is just one more chink in the MS Project armor.
The point of setting the task type to fixed work is to tell the tool that you
intend to arrive at your duration by estimating work. It seems silly that
Project still doesn't believe you when you say you have completed your
estimate by clicking "OK", and expects you to actually type in the duration
it just arrived at.

Can someone shoot holes through my argument, or is this really a design flaw?
Thanks.

 

[Mike Glen]

Hi Sandie,

I can neither shoot holes nor accept a flaw. Project's design favours what
it considers to be normal: the entry of Duration rather than Work when
you're building a project. I still find it difficult to understand why
planners convert the number of days/weeks/months to hours when Project will
do that for them. It's so much easier (in my opinion) to say "this will
take me 4, or 7 , or 10.... days", so why convert to hours? In your
situation, I assume you must have calculated the hours - why not just enter
the hours in the Duration column?

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

 

[JulieS]

Hi Sandie,

If you want to keep the ability to mark tasks as estimated but then
"re-set" them to non-estimated, add the Estimated field to the task
table. Once you have calculated the work and are content with the
duration, change the estimated flag to "no".

I hope this helps. Let us know how you get along.

Julie
Project MVP

Visit http://project.mvps.org/ for the FAQs and additional
information about Microsoft Project

 

[Sandie K]

Hi Mike,
For starters, let me say I bow to your wealth of knowledge and experience. I
really appreciate all you have contributed to the MS Project community.

Based on other posts I have read other to which you have contributed
regarding the topic of duration vs. work, as well as on what you say here, I
believe we are not necessarily on the same page on this topic. But I could
well be missing something. Please check my logic:

I have always estimated how many person-hours a task will take to complete
(especially for tasks I have done many times in the past). I do not
necessarily know the duration (in days anyway), because I usually have other
tasks to do also and won't be doing that one task in one sitting. So I allow
Project to tell me how many days that task will take after it has shared my
available time with all the other tasks I'm doing. (I always allow project
to express duration in days or fractions of days.) That's not to say I never
use fixed duration; I do use that when I decide I'm going to give myself a
fixed number of days over which to spread out a task. In fact, the course I
just took to prepare for Microsoft certification supported this concept.

Can I infer from what you are saying that you always use fixed duration for
your task type, or am I misinterpreting what you're saying?

As always, thanks for your expertise.

 

[Sandie K]

Thank you Julie! I was hoping there was a way to do it automatically, the way
it does with fixed duration tasks, but I guess not.

 

[JulieS]

You're welcome Sandie. I'm afraid there is no automatic way of
changing a single task to non-estimated other than unchecking the
option on the Schedule tab. That changes all the tasks, not
individual tasks. The estimated flag is still better than re-typing
durations.

Julie

 

[Mike Glen]

Hi Sandie,

Thanks for your kind words, though I'm not sure they're fully deserved

In my response, I never mentioned any Task Type as I'm of the opinion that
each of the three types has its usefulness. The point I was trying to make
is that to estimate in manhours is not a natural thing. I'm sure in my mind
that for more than a few days, you are unlikely to instinctively estimate,
say 47 manhours or 100 hours, but more like a week or 10 days or a month,
mainly because the estimating processes at the end of the day are, well,
estimates. Equally, if you ask others for estimates, they are likely to go
through the same process and convert the weeks, days, etc into manhours.
Have a look at your work estimates - how many round nicely into days or
weeks? So, I argue, why not just enter hours, days, weeks... into the
Duration column and let Project calculate the manhours.

Mike Glen
Project MVP

 

[Sandie K]

Hi Julie,
Actually, if the task is fixed duration, the ? will go away automatically
after you click "OK" in the task entry form. My point was that MS Project
appears to favor estimating tasks by duration rather than work.
Thanks,
Sandie

 

[JulieS]

Hi Sandie,

Thanks for your kind words, though I'm not sure they're fully
deserved

<snip>

I beg to differ Mike. You deserve all of Sandie's praise
Julie

 

[Mike Glen]

Aw, Gee (blush)

Mike

<snip>

I beg to differ Mike. You deserve all of Sandie's praise
Julie

 

[JulieS]

Hi Sandie,

I'm not seeing what you report. If I create a task with an
estimated duration, and change the task type to fixed duration, the
duration is still estimated -- question mark is still there. Even
after assigning resources, the estimated duration mark is still
there. (I'm using Project 2003 SP-3).

Project does have a bias towards duration in so far that when you
create tasks, duration is the only meaningful variable in the
duration, work, and assignment units relationship. You can add the
work field to a task view, but without resource assignments,
changing work has no effect on duration and changing duration has no
effect on work. As most people start creating a Project file by
listing tasks, then creating resources and assignments -- yes, I
suppose it is true that the initial estimates are duration based.

I do use fixed duration upon occasion to calculate assignment units
given a specified duration and work value. However, I rarely leave
tasks as fixed duration after calculating the assignment units
value. Generally, I work with either fixed work or fixed units more
commonly.

Julie

 

[Steve House [MVP]]

As far as I can see, this is just one more chink in the MS Project armor.
The point of setting the task type to fixed work is to tell the tool that
you
intend to arrive at your duration by estimating work. It seems silly that
Project still doesn't believe you when you say you have completed your
estimate by clicking "OK", and expects you to actually type in the
duration
it just arrived at.

Can someone shoot holes through my argument, or is this really a design
flaw?

Actually, Fixed Work is there so ccan edit an existing resource assignment
by changing the duration and have the units recalculated or change the units
and have the duration recalculated. It really doesn't have anything to do
with a preference for estimating work or duration when defining the WBS
except indirectly.

I personally have some difficulty with the idea of estimating work and
having duration calculated because I always wonder what real world
historical basis one has for making such estimates. For example, we can
reliably say from historical data that last year it took 2 weeks to roll-out
25 seats of a MS Office upgrade. That's duration data, not man-hours data.
It would be more difficult to say just how many man-hours that two weeks of
duration really represents. So this year we have to do 50 seats - which is
going to be more reliable estimate: "It should take us about 4 weeks" or "It
will require XX man-hours of effort?" Estimating man-hours worries me
because all too often it means the scheduler is planning a schedule that
meets an allowed man-hour budget rather than scheduling whatever work is
required to create the deliverable. Estimating work leads to a very strong
temptation to a schedule based on what is allowed rather than what will be
is required.

 

[Steve House [MVP]]

The default task type is actually Fixed Units, not Fixed Duration. I think
of fixed duration as being for those tasks that requires a specific number
of clock hours, such as a timed test process of some sort, for example.
Fixed Duration mens it will last exactly the designated time regardless of
how hard the resource works. If you have a Fixed Units task and edit Units,
it behaves as if it was Fixed Work and adjusts duration.

 

[Sandie K]

See, I'm not the only one who thinks so highly of you, Mike!
I want to thank you for taking the time to thoroughly understand and respond
to my question. For me, estimating in man hours has been the norm. I had
never thought about the possibility of developers converting duration into
hours. I need to be more conscious of this when asking for estimates. I will
try to be more open-minded about how I use duration.
Regards,
Sandie

 

[Mike Glen]

You're welcome, Sandie, and an open mind is the way to go.

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

 

[Sandie K]

Another very interesting and helpful perspective. Seems quite similar to
Mike's perspective, if I'm interpreting correctly. Thanks very much for
responding, Steve!
Regards,
Sandie