Calendar durations (again)

[Martin Wilkinson]

I want to do something really simple and I'm not sure the best way to do it.

I've read many of the posts on the subtleties of days per month, calenders
etc.

All I want to do is say that a particular task starts approximately 12
calendar months after an event.
I want to use this to represent an approximate lead time for component
delivery. So I have a "component ordered" milestone, followed by a "component
delivered, work can start" task. I have linked the 2 tasks and added a 12
month lag.

If I use reasonable Tools/Options/Calendar settings (7.5 hrs/day,37.5
hrs/week,20 days/month), and set the first milestone to 1 Nov 05, the linked
task is driven to start on 12 Sep 06, which is about 6 weeks adrift. I don't
need it to be very accurate, but more accurate than this.

If I set days/month to 23 then they line up OK (to within a week). Is this
the best/only way? Will this cause me any other problems? What do other
people use for days/month?

I tried setting the lag to 12 emons (elapsed months) but this drove the task
29 June 06 (even worse!). Don't quite understand this.

Anyone know why the default Calendar setting of days/month is 20 which can
give such a big errors?

I suppose what I really want is to be able to tell Project to use
approximate calendar days/months for specific durations/lags, but it seems to
be too analytical to do that.

Anyone have any thoughts?

 

[Jan De Messemaeker]

Setting any conversion factor (20, 23, any) can never cause you problems.
It's just a conversion factor.
Project calculates everything by the minute anyway so all it is used for is
to find out what you mean by "a month" so that it can convert it into
minutes.
HTH

 

[Mike Glen]

Hi Martin,

Can't you use a lag of 52 weeks or 365 days?

FAQs, companion products and other useful Project information can be seen at
this web address: http://project.mvps.org/faqs.htm

Hope this helps - please let us know how you get on

Mike Glen
MS Project MVP

 

[Martin Wilkinson]

Hi,
Great idea, but I seem to get strange results whatever unit I express the
lag in. I suppose this thread should be named Lag Durations. I think I've got
my head round what Duration means when applied to a task, but lags are still
confusing me.

You can see what I mean if you try the following (or I can email you a
simple example). I am trying to get Task 2 to start 1 year after Task 1.

Start Project (2000) and create a new schedule. Tools/options/calendar
defaults to 7.5 hrs/day, 32 hrs/wk, 20 days/month.

Create 2 tasks, link them and apply a lag (F-S) of 365 days to the link.
Results below, together with other lags I've tried.
The closest I get to the desired result of Task 2 starting on 2 Jan 2007
(approx) is to use a lag of 278 (about 14 MSP "months" at 20days/mon). I
don't understand why.
I tried reducing the lag by 1 day at a time and confirmed that it does use
working days (it skips from Monday to Friday when you reduce by 1 day). I
tried 260 days because I guessed this is how many working days Project thinks
there are in a year (based on the Tools/options/calendar, 52 weeks in a year,
which is 13 MSP "months" at 4 weeks/month, then 20 days/month) and this is
the closest I get, but still 3-4 weeks out.

There are no resources applied to any of the tasks.

Lag Task 1 Start & Finish Task 2 Start

365 days 2 jan 06 26 April 07
52 weeks 2 jan 06 19 Oct 06
12 mons 2 jan 06 13 Nov 06
260 days 2 jan 06 8 Dec 06
12 emons 2 jan 06 30 Aug 06
278 days 2 jan 06 2 Jan 07 (!!)

I'm not after precision to the nearest day, but MSP is obviously performing
a repeatable calculation & I can't see the logic behind it which is
frustrating!

The impact of all this is that I can't confidently add leads/lags in units I
understand (days/weeks or whatever) without having to check them afterwards
and "frig" them to get the dates I want. I'm sure this is not what was
intended by the MSP designers, unless there's a bug.

Any light thrown would be appreciated!!

Regards
Martin

 

[Jan De Messemaeker]

Hi,

How many working minutes are there in Tools, Change Working tiome calendar?

 

[Mike Glen]

Hi Martin,

Try 365edays (the e is for elapsed)


Mike Glen
Project MVP

 

[JulieS]

Hi Martin,

In testing, I created the simple project as you suggest. (Using MS Project
2003 - although that should not be the issue.) Start date of Project is 2
Jan 06. In the project calendar (Tools>Change Working Time) I modified all
working days to a 7.5 hour day (08:00 to 16:30 with .5 hours off). In Tools

Options, Calendar tab -- Hours per day = 7.50, Hours per week = 37.50. (I

noticed you mention in your post that you set Hours per day at 7.50 and
hours per week at 32).
The project calendar has no holidays (non-working time other than Saturday
and Sunday). Two tasks (A & B) linked F to S, with Task A having 1 day
duration.

Lag Start - Task A Start - Task B
365 days 02 Jan 06 29 May 07
365 edays 02 Jan 06 03 Jan 07
52 weeks 02 Jan 06 02 Jan 07


Like duration, when is lag expressed as days, weeks, or months it is always
based upon the definition of day, week and month set in the Tools >Options,
calendar tab but it is always *working* days, weeks, or months as defined in
the project calendar. When using elapsed units, the measurement disregards
working and non-working time. So 365 edays is 365 calendar days -- each day
being 24 hours.

I suspect there is a mis-match between the project calendar (Tools > Change
Working Time) and the definition of hours per day and hours per week.

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

Julie

 

[Martin Wilkinson]

The default "Standard(Project Calendar)" which shows 08:00-12:00 and
13:00-17:00. I assume the minutes/day is then 8hrsx60=480.

Is this what you meant?

Regards
Martin

 

[Martin Wilkinson]

I think I've sorted this all out now. I set my Working Time and
Tools/options/calendar to what you suggested and I can explain the results
for the various units of lag (month, eday etc. etc.).

My basic problem was that I had rashly assumed that the Default values for
Working Time and Tools/options/calendar when I open a blank Project would be
consistent. This is not true. Tools/options/calendar defaults to 7.5 hrs/day,
32 hrs/week and Working Time defaults to 8.00 hrs/day, 40 hrs/week. This
causes the inconsistency and inexplicable results; nothing else.

I know the mantra is to make sure they are consistent, but Project really
should start up with consistent values.
Very tardy.

Thank you for everyone's time & patience

 

[Jan De Messemaeker]

Hi,

The default default is consistent.
Somebody miust have "set as default" these inconsistencies.
HTH

 

[Steve House [Project MVP]]

The confusion also results from the fact that the number of working minutes
that count towards duration is defined by the calendar shown in the "Change
Working Time" screen. The Options settings of Hours per Day, Hours per
Week, and Days per Month do not control duration or calendars as such at all
but instead merely set up conversion factors for convenience in entering
duration units. If the two areas are consistent there should be no problem
but if they're not and it's easy for them not to be consistent, all kinds of
headaches can result. For example, there's nothing to prevent me from
entering that my working hours are 0800-1200 and 1300-1600 yet the Option
page says that there are 8 hours in a "day". So if I have a task starting
Monday at 8am and set its duration to be "1 day," Project says that 480
working minutes must elapse from the time it starts until it's done.
Starting at Monday 8am and running until 4pm, this task only consumes 420
working minutes so there's still an hour to go. So a 1 day task in this
project starting at 8am on Monday finishes at 9am on Tuesday

 

[JulieS]

Hi Martin,

Glad you were able to sort it out and thanks for the update.

As Jan mentioned, the Tools >Options calendar tab Hours per day and Hours
per week is set by default to 8 hours and 40 hours. Those match the
"Standard" calendar. Someone must have changed to the other definition and
clicked the "Set as Default" button on the Calendar tab.

Hope this helps.

Julie

 

[Martin Wilkinson]

I've had Project installed on this PC for several years (from when I started
working with it) so it's entirely possible I'd changed the defaults in my
early days without realising the horrendous confusion it could cause.

I consider myself suitable cowed and will henceforth never have my calendar
inconsistent with my Working Time!

And sorry for thinking Project could be imperfect

Martin

 

[Steve House [Project MVP]]

It's hard not to have them out of sync every once in a while. Let's say you
have some resources that work 8 hour per day, 40 hours per week, and others
that work 7 hours per day, 35 hours per week. And there's a thrid group
that also works 40 hours per week but in 4 10-hour shifts. The calendar
that governs "duration" is the calendar governing the task. But the
conversion of "day" to hours is a global setting. Suing the standard
settings, I say that a task starting Monday is to be a 5 day duration task.
If I assign a resource from the 8/40 hour group to it, "5 days" will end
Friday afternoon at 5pm. But if I assign a resource from the second group,
"5 days" ends the following Monday afternoon. And if I assign a resource
from the third group, the same "5 days" will end Thursday at 6pm.