Actual months

[tshad]

How do you tell the program to run for 3 months?

The problem is that if I say start on 01/01/09, it will go to 03/25/09 when
I really want it to go to 03/31/09.

I then need to have the lag date 1 month so it starts at 02/01/09, but
instead when I enter 1mo it goes to 01/29/09.

This project is going to start on the 1st day of the month and all the tasks
are going to run for even months (months 2-4 or 5-9).

I want to be able to change the start date to 02/01/09 and have it calculate
the dates correctly.

Is there a way to do this?

Also, how can can I have the milestone start on the next day? If I have a
task that stops on 12/31/09 and then a milestone which says "Phase 2 Year
2" - It shows the milestone on 12/31/09 instead of 01/01/10.

Thanks,

Tom

 

[Jim Aksel]

You have a couple things going on here. First, Project does not understand a
Fiscal Calendar without some programming. The reason you are getting "odd"
dates when you enter durations of 1mo, etc. is the definition Project is
using for these values. Go to Tools/Options and pull the Calendar Tab. You
will see the default number of days in one month is 20 work days. As we all
know, this is an average representing 4 weeks per month. Sorry, no way to
make the value different. The alternative is to enter the task duration in
work days, not months.

Use the Adjust Dates feature (an icon on the Analysis Tooolbar).
View/Toolbars... select Analysis. Click on the button and it will ask for a
new start date. It will shift everything to start on the new date as if you
had done it that way originally.

To force a task to start at 8AM on a specific day you need to play a trick.
First make a special calendar that has only 1 minute of scheduled work hours
available at say 5:01PM every day. Give the calendar a special name so you
know what it is. Let's call it "LastMinute".

You have your regular task finishing 12/31 somewhere near 5PM. Add a new
dummy task below that one and make a milestone on that new line, some people
use a 1 minute duration task. The task name is "Dummy" or anything like
that. Make the predecessor to that task the one finishing on 12/31. Asign
the calendar "LastMinute" to task "Dummy." Following task "Dummy" is your
Phase 2 Kick-Off milestone with the standar calendar assigned. It's
predecessor is "Dummy". This forces the task to start first thing on the
following day. With a little thought in developing the "LastMinute"
calendar, you can force tasks to start on specific days of the week. For
example if the calendar contains one minute of work on Wednesdays at 5:01PM
every week, then any task following "Dummy" would always start on Thursday at
8AM. This means "Task1" could finish on Monday at 3PM and be linked to
"Dummy" that ends Wednesday. The task following "Dummy" would start
Thurdays. The overall effect is to create a lag between Task1 and what
follows Dummy.

Post back for more clarification.


--
If this post was helpful, please consider rating it.

Jim

Check out my new blog for more information:
http://www.msprojectblog.com

 

[Jim Aksel]

Clarification. You can change the number of work days in a month, but the
value selected is the same for every month.

 

[Jack Dahlgren]

True,

The "Average" number of days in a month is really 21.7
So setting the month to be 22 days will get you closer to being actual
months - close enough I think - but will still be wrong most of the time.

-Jack Dahlgren

 

[tshad]

True,

The "Average" number of days in a month is really 21.7
So setting the month to be 22 days will get you closer to being actual
months - close enough I think - but will still be wrong most of the
time.

It will.

I tried usint "emon" and it was close but it apparantly using 30 days per
month so doesn't work either.

I just want my tasks to start on the first day of the month and end on the
last day - which I finally did by putting the duration to 193 days or 59
days on each each task to get it to work. The only problem is that if I
change the start date from 1/1/2009 to 2/1/2009 than I will have to go
readjust all the tasks with different durations.

Did the job temporarily.

Not sure why it doesn't have a duration type that would handle an actual
month, though.

Thanks,

Tom

 

[Steve House]

There are a couple of fundmanetal problems to discuss here. First and
foremost is that the purpose of a scheduling tool is not to document the
dates you feel (or need) the tasks to take place - it is rather to calculate
for you the dates when tasks CAN (or ought to) take place. You don't tell
it the schedule - you tell it what needs to be done and it tells YOU when to
do it. When you are attempting to input Task X to start on the 1st of July
and end the 31st of July you are trying to drive the schedule into some form
that you have already created apriori, using a scheduling workflow that runs
totally counter to the reason scheduling software was created in the first
place. You might be able to legitimately say "If this task starts on 01
July it is likely to require 160 working hours to complete and it needs to
be finished by July 31st" but there's no way you can establish by
declaration that it WILL start and end on those or any other dates.

Second, tasks don't drive forward based on the passsage of time, they drive
based on the performance of work. "Duration" includes only working time
minutes - any non-working time is irrelevant to achieving the project's
objectives and is not considered when building the schedule. MS Project
ALWAYS deals with task times in working time minutes and that is the only
'real' unit of duration - any other units you see or use are only displayed
as a concession to user convenience. No matter whether you work in hours,
days, weeks, months, or years, Project must convert it into equivalent
working time minutes for all its internal computations. That's why you're
running into the issue - because of days off, holidays, etc there are a
different number of working time minutes between June 1st and June 30th than
there are between July 1st and July 31st than there are between August 1st
and August 30th and as far as scheduling is concerned, the passage of
working time minutes is the ONLY thing that matters. "One Calendar Month"
is a moving target as far as measuring the time required to drive a
project's task forward, the actual working time it encompasses changing for
virtually every month of the year and even from one year to the next. 20
working days, or more accurately 9600.0 working time minutes, on the other
hand is a fixed, predicatable, and measurable amount of time that is
required to complete a task whereas "1 calendar month" is not.

HTH