Prev: Date 1 field not updating automatically
Next: Planned vs Actual Percentage Completed
From: "Steve House" sjhouse at hotmail dot on 15 Jan 2010 11:25
You might point out to the boss that tasks always produce something in a
definite quantity, as an example we need precisely 100 widgets. We don't
work to make a certain amount of time pass, we work to make 100 widgets. If
a worker makes 20 widgets a day, we don't start and then stop 5 sunrises and
sunsets later (working either 3 days, 4 days, or all 5 days in the process
depending on our pattern of days off), making however many widgets can get
made get made in that time. Instead we work for how ever many workdays it
takes us to make the required 100 widgets, no more and no less. The worker
who makes 20 widgets a day has to spend 5 work days to do it, also no more
and no less. If he works 5 days a week, M-F, and starts on Monday, there
will be 4 sunsets before the day he finishes the 100 widgets. If he works 5
days a week M-F and starts on Wednesday, there will be 6 sunsets before he
finishes the 100 widgets. If he only works 1 day a week, there will be
about 35 sunrises and sunsets before he finishes 100 widgets. That's why if
we know the date he will start and need to know the date he'll end, so we
can tell the person who needs the widgets for his own work when to expect
them, we have to use working days for our scheduling and not just regular
calendar days or elapsed time. In fact, in terms of creating a project work
schedule, elapsed time using units such as "calendar weeks" and "calendar
months" are pretty much meaningless since the schedule simply must take into
account what portion of the elapsed time is productive and what portion is
not.

--
Steve House
MS Project Trainer & Consultant


"Michael T" <chilledmonkeybrains100(a)gmail.com> wrote in message
news:u7ci0o7kKHA.4500(a)TK2MSFTNGP06.phx.gbl...
>
>
> Sai wrote:
>> On Jan 12, 9:40 am, Michael T <chilledmonkeybrains...(a)gmail.com>
>> wrote:
>>
>>>Many eons ago using an early version of Project, I could enter tasks of
>>>30, 45,
>>>60, 75 days, etc., duration to mean a month, month-and-a-half, etc., and
>>>the
>>>program understood I meant for these time blocks to span non-working days
>>>(weekends); so for example, a "30-day" task entered on May 1 would finish
>>>June 1.
>>>
>>>Fast-forward to the present day, and my Project 2007 interprets "30 days"
>>>to
>>>mean 30 *work* days rather than 30 calendar days.
>>>
>>>How can I use 30/45/60/75 etc., again and get the durations I used to? A
>>>few
>>>googlings hinted this'd be a setting in Tools> Options, but nothing there
>>>jumps
>>>out.
>>>
>>>Grateful for any clues or pointers to a good newbie FAQ.
>>>
>>>Michael
>>
>>
>> Michael -
>>
>> To enter calendar days, you need go for elapsed days. Elapsed days
>> ignores the distinction between working and non working time on
>> calendars. So, instead of entering 30 days, type 30 edays.
>>
>> Refer: http://alturl.com/wcg5
>>
>> Please let us know if this helps
>>
>> - Sai, PMP, PMI-SP, MCTS, MCT
>> http://saipower.wordpress.com
>
> Sai - Is there any way to make the duration column *say* days but mean
> edays? (Boss points out 'edays' is not exactly user friendly....)
>
> TIA
> Michael

First  |  Prev  | 
Pages: 1 2 3
Prev: Date 1 field not updating automatically
Next: Planned vs Actual Percentage Completed