Newbie - Enter "normal" task durations: 30-day 45-day etc

[Michael T]

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

 

[Sai]

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 finishJune 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 therejumps
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

 

[Guest]

You're not pulling our legs are you?
An eon is a long time, certainly back to sometime before software existed.
You need to recalibrate your fuzzy recollection of how you think you
remember it working eons ago, and your expectations of how MSP works now.
Probably best to forget about the recollections and expectations and focus
on here and now.

30 days has never been a calendar month and duration has always been working
days as defined in the project calendar (or the task calendar if there is
one).

In Tools, Options, Calendar, the default is 1 month = 20 days (that's
working days).
This means that if you input 1 month as a duration, MSP converts it to 20
working days.
You can change it but it is better not to mess with it and just input
duration in days.

If you input 45 days, the bar in the Gantt Chart runs through the
non-working days but they aren't counted in the 45.
The finish date falls wherever it falls, not on a particular date of a
particular month.

Suggestion: do not pursue your line of thinking on this or you will be
annoyed and frustrated.

In addition to Trevor's good advice, I'll add a word or two of my own.

A widely accepted heuristic in Project Scheduling is that tasks should be
between 1 day and 10 days in length. Why? Shorter tasks are microplanning
and will drive you crazy trying to track them all. Longer ones give
resources the opportunity to blow out your schedule. What happens if at the
end of 60 days on a critical task, you find out nothing has been
accomplished? You're now 3 months behind schedule. It happens.

You need a deliverable at least every 10 working days, if not more. That
way, you know where you are. Unless of course, you trust every resource to
never mislead you on progress reporting. In which case, you have much, much
bigger problems than how M$ Project interprets durations!

Hope this helps.

 

[Michael T]

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 - That works beautifully, I really appreciate the tip! Pity I don't see
'edays' documented anywhere.

Trevor and spamboy - Thanks for the elaboration, but I think you may idealize
the typical frantic office and the trainability of the annointed ones. My bosses
would return only belly-laughs if I suggested they modify the 30/45/60/etc
concepts that they toss around so freely and frequently.

Michael

 

[Michael T]

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

 

[Rob Schneider]

No.

I had a boss like that once. Solution was to keep her/him (I'm not say
which) as far away as possible from the project. Things went prety well
after that.


--rms

www.rmschneider.com

 

[Sai]

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- Hide quoted text -

- Show quoted text -

No. Sorry, you need to indicate somewhere it is calendar days and so
edays is MUST

- Sai

 

[Steve House]

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.