Project Duration

[Annabelle]

I am fairly new to the use of Project and I am a little confused on the
project duration. In the duration period, I put 12 months but my start and
finish date are 11/1/05 and 10/2/06. Based on my calculations this is really
only 11 months. Why is this? I have the calendar set at the standard 24
hour project calendar. Am i supposed to type something else besides 12 mo in
the duration to get the correct end date? Any help would be much appreciated.

Thank you

 

[JulieS]

Hi Annabelle,

In Tools>Options, calendar tab the default definition of the duration of
"month" equals 20 days. When you enter a 12 month duration Project
calculates 20 *working days* per month times 12. Try 52 weeks and you'll
see then end date of 30 October 2006.

Also take a look at FAQ #5 at:
http://project.mvps.org/faqs.htm

Hope this helps. Let us know how you get along.

Julie

 

[Steve Scott]

Have you checked the no of days per month ie Tool/Options/Calendar tab? This
is used to calculate how long a month is in days.

Rgds

Steve

 

[Steve House [Project MVP]]

Firstly, duration only includes working time - non-working days such as
weekends do not count. Second, all durations are actually stored and
computed in hours (actually minutes if you get picky about it). So when you
say a task has a duration of "1 month" Project has to convert that into the
"real" duration units of hours for processing and storage. And it works the
same process in reverse to convert from hours in the database to get to
whatever units you like to see durations in. So for your example, if the
"days per month" field (Calendar Options) is at the default 20 days,
entering "12 months" for a task duration gets converted to 12*20=240 working
days (we'll simplify and ignore the further conversion to hours). Assuming
you work 8-5 Mon-Fri, start at 01 Nov 05 and count off 240 workdays in the
calendar, skipping any non-working days and holidays you've entered into
your calendar, and you'll end up at 02 Oct 06

Be very very careful using the 24 hour project calendar. It's rarely
appropriate. That calendar says that when work starts on a task, it
proceeds in a continuous block 24 hour per day, 7 days per week until it's
done. But when the project is properly broken down into tasks, a single
task will represent the work done by ONE resource or resource team working
together as a unit. So using the 24 hour calendar says that if Joe Schmoe
is assigned to a 2 week task starting Monday, he won't see the light of day,
have any time off, have a meal or see his family or take a nap, for two
solid weeks of non-stop work until the task is done. Machines might work
like that but people don't and tasks are done first and foremost by people
working a normal work schedule of some sort. That generic normal schedule
is what your project calendar should reflect. IF you operate 24 hours a
day, I'd create at least 3 calendars reflecting day shift hours, swing
shift, and graveyard. I'd pick one of those, probably the day shift, and
designate it as the project calendar so it will schedule tasks tentatively
as if they're going to be done by a day shift worker until such time as I
decide who I'm really going to put on them. Because task schedules normally
follow the work schedule of the resources assigned to them, if I then put a
swing shift worker on it, its hours will switch to swing shift as it should.