experchange Duration 1 month = 1 calendar month

 Matt Schiemer (02-16-06, 05:52 PM)
I need help with getting the "duration" of 1month to equal one calendar month
in terms of start and finish times. When I set the calendar to a 7 day work
week it seems to work for a duration set in days (i.e., 365 day duration with
1/1/06 start date will show end date of 12/31/06), but if I input a duration
of 12 months for that same 1/1/06 start date, it goes from 1/1/06 to 1/7/07.
Why won't 12 months also finish on 12/31/06?? How can I get one month to
equal one month??

 John (02-16-06, 06:20 PM)
In article <0833DFFD-DCD0-4715-90D4-2CCE3697BE8B>,
"Matt Schiemer" <MattSchiemer> wrote:

> I need help with getting the "duration" of 1month to equal one calendar month
> in terms of start and finish times. When I set the calendar to a 7 day work
> week it seems to work for a duration set in days (i.e., 365 day duration with
> 1/1/06 start date will show end date of 12/31/06), but if I input a duration
> of 12 months for that same 1/1/06 start date, it goes from 1/1/06 to 1/7/07.
> Why won't 12 months also finish on 12/31/06?? How can I get one month to
> equal one month??

Matt,
Because Project does not use a lunar calendar. That is, some months have
30 days and most others have 31. However the real answer to your
question is a settings found under Tools/Options/Calendar tab. The
setting for "Days per month" is based on a default 20 working days per
month and that's what Project uses when it calculates duration in
months. You could reset it to be 30 days per month but then it wouldn't
track with Feb, Mar, May, etc.

Not the answer you were looking for but if you want more-or-less exact
durations, use "days". You can set the duration to be elapsed days if
you want. To do that add "ed" to the Duration value.

John
Project MVP
 Matt Schiemer (02-16-06, 07:36 PM)
Thanks, John. I'm very surprised that Project can't deal with lunar (normal)
calendar months. I've noticed several other comments/questions regarding
this issue -- hopefully it's something that Microsoft can build into future
versions...

Thanks again.

"John" wrote:
[..]
 John (02-16-06, 11:35 PM)
In article <E48F9018-1A7B-480B-8C04-A081AFA9B235>,
"Matt Schiemer" <MattSchiemer> wrote:

> Thanks, John. I'm very surprised that Project can't deal with lunar (normal)
> calendar months. I've noticed several other comments/questions regarding
> this issue -- hopefully it's something that Microsoft can build into future
> versions...
> Thanks again.

Matt,
You're welcome. If enough people request a feature, I'd say there is a
good change a future version will incorporate it.

John
[..]
 Steve House [Project MVP] (02-18-06, 01:54 PM)
The reason is that duration only includes working time, not elapsed time.
The same thing happens with a "day." A duration day is not 24 hours, the
time between one sunrise and another. It is a working day, typically 8
hours, the time that passes between when an individual resource comes in to
work and when he goes home for the day. The elapsed hours when that
resource is not there during a day or a week or a month simply don't count
for duration. For planning purposes they might as well not exist at all. A
basic question Project seeks to answer is "If task X requires this many
man-hours of effort to achieve its results and we can start on Monday, when
will we finish it?" Only times when people are physically present working
will count to burning up required effort hours. Nothing happens during
non-working time and so no progress is made during those hours. As a
result, saying "I expect this task to take 3 calendar months" doesn't really
convey any information about the task since it fails to take into account
how much of that 3 months is productive time and how much is non-productive
time. Remember Project tracks everything down to the minute and the ability
even to use months as a unit in the first place is structly there as a
convenience for planning to a very rough crude approximation. When you get
to planning the real schedule you need to be thinking in smaller units than
that. - I like to remember the 8/80 rule, which says tasks should be longer
than 8 hours but less than 80 - over 80 you're not planning in enough detail
to effectively manage the work and under 8 you're meddling excessively in
the resource's workday. There are exceptions to that, of course, but it's
still a pretty good guideline.
 Matt Schiemer (02-20-06, 06:01 PM)
Steve -

Thanks for the very thorough explanation.

I guess my comment would be that MS Project is too smart and detail-oriented
to handle high-level planning. I'm working on a project that involves many
related projects that each have a duration of one to several years and I'm
trying to lay them out, showing predessors, etc... the accuracy to which we
know the duration of any of the projects (or its sub-tasks) is no better than
within a month or even a quarter (of a year). So, for me I just want to work
in calendar months as my smallest unit of time (not seconds!). I'm forced to
"fake" it in by adjusting my duration for each task one day at a time until
the start dates are exactly the first of a calendar month. The only problem
is when I adjust one task that's connected to others, I'm getting start dates
that push to the 2nd of the month sometimes, so I have to recheck each and
every task's start date every time I make a change to one task (there are
over 100 tasks right now, so it's getting time consuming).... even "elapsed"
time doesn't work. somehow it doesn't match calendar months. Also, I can't
really utilize the duration column in the schedule because it says 427 days,
which means nothing to me at a glance. I need it to say 14 months. When I
put in 14 months, or even 14 emons, my start/end dates get funny....

So, just to confirm, there's no other way for me to achieve this in Project
other than "faking" it as I'm currently doing?

-Matt

"Steve House [Project MVP]" wrote:
[..]
 Steve House [Project MVP] (02-20-06, 07:17 PM)
You might want to re-think how you're using Project. It's really not
designed to document a plan you have already worked out and that's sort of
what it sounds like you're doing. Try to reverse the process - instead of
thinking in terms of broad spans of time, start at the lowest level and plan
from the ground up. A project that last a year or two is going to involve
hundreds if not thousands of detail level tasks. But when you start to pump
this into Project you don't have a clue that it will take 15 months with the
first phase lasting 3 1/2 months etc, much less know that you should start
Phase 2 on September 1st. What you know is that it takes a plumber 2 days
to install a toilet and during Phase 3 of the project you'll need to install
27 toilets. You input that into MS Project and it tells you what date you
can do it.

As a general process, you decompose the work from the top down, from the
broad level scope statement of what needs to be accomplished down to the
level of the detailed list of specific activities that will accomplish it.
Then you schedule from the bottom level up, plugging in the estimates of how
long each lowest level detail activity will take and letting Project
determine the start and finish dates for each level going up until you see
the start and finish of the overall project plan.

If we can, just for clarity of discussion lets call your over-all plan the
"project." What you're calling the several projects let's call
sub-projects. They in turn consist of several summary tasks describing
broad deliverables which are eventually further broken down into performance
tasks that describe real work actions done by real people.

Even for the highest level planning you don't input dates. You know when
you're going to kick-off the project, you know it will require 5 major
phases, and each phase is a sub-project will require about X number of
months to implement. You've said you don't know the duration of any of
sub-project to better than a month or even a quarter year yet you're worried
that MSP shows the start date of the next one in line as Sept 3 instead of
Sept 1!! The accuracy of your dates can NEVER be any better than the
accuracy of the duration estimates. If sub-project A is 1 year starting
March 1st and you know that duration to an accuracy of +/- 2 months (ie,
will be somewhere between 11 and 13 months), then the start date of
successor sub-project B simply cannot be determined with more accuracy than
range 01 Feb 07 to 01 Apr 07 anyway and any arbitrary start date for B close
to that range is just as good as any other. Worrying about whether it's
showing 15 Feb or 1 Mar or 15 Mar is simply maintaining an illusion of
precision since you really might as well be just putting slips of paper with
dates within the range written on them into a hat and drawing one at random
as far as predicting what's really going to happen a year or so down the

Another thing you might find useful at this point are the PERT tools in MSP.
It allows you to input best case, likely case, and worst case duration
estimates and calcualtes a weighted average duration. The result allows you
to create a schedule that's sort of 3-in-one, displaying best, klikely, and
worst case Gantt charts. Setup your subprojects initially as tasks with the