Let's see if anyone in the world can help me on this one!

I've been using MSP for several years now (currently on MSP 200)...and I
hope that I'll explain my predicament succinctly

I can set-up the calendars, Change Working Time, and custom calendars
without too much difficulty....and I fully understand (I think!) the settings
via Tools/Options/Calendar (TOC)..which sets the definition of how many hours
equals one working day.

The Problem: If I apply a custom task or resource calendar to that task,
then the start of the task amends in accordance with the custom calendar
(good!), but the duration (therefore the end-date) alters in accordance with
how many hours-per-day have been defined in the TOC settings, regardless of
the working-times set by the custom calendar. This results in an incorrect
number of hours work for the resource, unless I go into each task and amend
the work in accordance with the true working times of the resource.

The Example: The basic/project calendar has been set for 06:00 start: and
18:00 finish, with 12 Hrs-per-day. The basic resources have also been set in
accordance with those times...thus giving a correct 12 hrs work for a 1 day
task duration. A custom task and custom resource calendar has been configured
for an 8 hour working day, starting at 08:00. However, when applying the
custom task/resource calendar, the task finishes at 12:00 on the following
day. This indicates that a 1 day task duration equates to 12hrs work, even
though a custom calendar's working day has been defined at 08:00-17:00. This
all seems to come-about because you can define only one set of Hrs-per-day
(in TOC).

The Question: Is it possible to configure the calendars such that, when you
apply a custom resource/task calendar, the default task duration of 1 day is
read in accordance with the working-times specified by the custom
calendar....thus also applying the correct number of working hours?

Have I missed something; is this an "operating characteristic", or do I have
to trick MSP into doing what I would like it to do?

Thanks for any tips or guidance.

James. G

Re: Custom Calendars in MSP 2000 by Mike

Mike
Wed Sep 08 06:07:24 CDT 2004

Hi James,

Welcome to this Microsoft Project newsgroup :-)

Tha answer to your question is Yes. But you must set up all these
parameters BEFORE entering any data (perhaps use a template for new projects
see the FAQs). The TOC settings are the defaults that Project uses, but
Project will not change what has already been entered. If you change the
TOC with already entered data, you will have to go back through the tasks
and re-enter their Durations - shouldn't take too long as the Durations are
already there - re-entering them will force Project to recalculate as you go
along..


You might like to see FAQ Item: 5. Default Working Hours

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

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

Mike Glen
Project MVP
James G wrote:
> Let's see if anyone in the world can help me on this one!
>
> I've been using MSP for several years now (currently on MSP
> 200)...and I hope that I'll explain my predicament succinctly
>
> I can set-up the calendars, Change Working Time, and custom calendars
> without too much difficulty....and I fully understand (I think!) the
> settings via Tools/Options/Calendar (TOC)..which sets the definition
> of how many hours equals one working day.
>
> The Problem: If I apply a custom task or resource calendar to that
> task, then the start of the task amends in accordance with the custom
> calendar (good!), but the duration (therefore the end-date) alters in
> accordance with how many hours-per-day have been defined in the TOC
> settings, regardless of the working-times set by the custom calendar.
> This results in an incorrect number of hours work for the resource,
> unless I go into each task and amend the work in accordance with the
> true working times of the resource.
>
> The Example: The basic/project calendar has been set for 06:00 start:
> and 18:00 finish, with 12 Hrs-per-day. The basic resources have also
> been set in accordance with those times...thus giving a correct 12
> hrs work for a 1 day task duration. A custom task and custom resource
> calendar has been configured for an 8 hour working day, starting at
> 08:00. However, when applying the custom task/resource calendar, the
> task finishes at 12:00 on the following day. This indicates that a 1
> day task duration equates to 12hrs work, even though a custom
> calendar's working day has been defined at 08:00-17:00. This all
> seems to come-about because you can define only one set of
> Hrs-per-day (in TOC).
>
> The Question: Is it possible to configure the calendars such that,
> when you apply a custom resource/task calendar, the default task
> duration of 1 day is read in accordance with the working-times
> specified by the custom calendar....thus also applying the correct
> number of working hours?
>
> Have I missed something; is this an "operating characteristic", or do
> I have to trick MSP into doing what I would like it to do?
>
> Thanks for any tips or guidance.
>
> James. G



Re: Custom Calendars in MSP 2000 by Mike

Mike
Wed Sep 08 11:46:22 CDT 2004

Hi James,

Whatever you enter as Duration is interpreted by Project by the TOC settings
and is applied to the Standard calendar. If the task calendar applied is
different, then Project will take the Duration as being that which has been
entered as above and span that across the task calendar. So if you enter 1
day as being 12 hours defined in the TOC, and apply an 8 hour task calendar,
Project will identify the task as requiring 12 hours of work and the task
will thus finish at mid-day the next day. That's the way Project works. If
you have any doubts about this, use a split screen and enter the hours of
Work and set the Duration accordingly. Alternatively, enter the Work data
in one of the Usage views.


Mike Glen
Project MVP



James G wrote:
> Mike,
>
> Thanks for the rapid response. I did set-up all the calendars etc.
> prior to entering any data...and this is why I'm somewhat perplexed.
> After having visited your web-site, it only confirmed that which I
> was already doing.
>
> Of course, once I entered the resource's correct "work" for a
> customised 1 day task duration, the duration then reduced
> accordingly. However, I'd expect the duration still to read 1 day,
> but interpreted as 1 "custom day". Although I'm not too worried about
> this particular aspect. My main concern still lies in the fact that,
> despite applying the customised task/resource calendar, it uses the
> TOC setting to calculate the hrs-per-day. Can you confirm, to the
> best of your knowledge, that if you apply a custom calendar, the task
> duration should start/finish in accordance with those times?
>
> Thanks.
>
> James.G
>
> "Mike Glen" wrote:
>
>> Hi James,
>>
>> Welcome to this Microsoft Project newsgroup :-)
>>
>> Tha answer to your question is Yes. But you must set up all these
>> parameters BEFORE entering any data (perhaps use a template for new
>> projects see the FAQs). The TOC settings are the defaults that
>> Project uses, but Project will not change what has already been
>> entered. If you change the TOC with already entered data, you will
>> have to go back through the tasks and re-enter their Durations -
>> shouldn't take too long as the Durations are already there -
>> re-entering them will force Project to recalculate as you go along..
>>
>>
>> You might like to see FAQ Item: 5. Default Working Hours
>>
>> FAQs, companion products and other useful Project information can be
>> seen at this web address: http://www.mvps.org/project/
>>
>> Hope this helps - please let us know how you get on :-)
>>
>> Mike Glen
>> Project MVP
>> James G wrote:
>>> Let's see if anyone in the world can help me on this one!
>>>
>>> I've been using MSP for several years now (currently on MSP
>>> 200)...and I hope that I'll explain my predicament succinctly
>>>
>>> I can set-up the calendars, Change Working Time, and custom
>>> calendars without too much difficulty....and I fully understand (I
>>> think!) the settings via Tools/Options/Calendar (TOC)..which sets
>>> the definition of how many hours equals one working day.
>>>
>>> The Problem: If I apply a custom task or resource calendar to that
>>> task, then the start of the task amends in accordance with the
>>> custom calendar (good!), but the duration (therefore the end-date)
>>> alters in accordance with how many hours-per-day have been defined
>>> in the TOC settings, regardless of the working-times set by the
>>> custom calendar. This results in an incorrect number of hours work
>>> for the resource, unless I go into each task and amend the work in
>>> accordance with the true working times of the resource.
>>>
>>> The Example: The basic/project calendar has been set for 06:00
>>> start: and 18:00 finish, with 12 Hrs-per-day. The basic resources
>>> have also been set in accordance with those times...thus giving a
>>> correct 12 hrs work for a 1 day task duration. A custom task and
>>> custom resource calendar has been configured for an 8 hour working
>>> day, starting at 08:00. However, when applying the custom
>>> task/resource calendar, the task finishes at 12:00 on the following
>>> day. This indicates that a 1 day task duration equates to 12hrs
>>> work, even though a custom calendar's working day has been defined
>>> at 08:00-17:00. This all seems to come-about because you can define
>>> only one set of Hrs-per-day (in TOC).
>>>
>>> The Question: Is it possible to configure the calendars such that,
>>> when you apply a custom resource/task calendar, the default task
>>> duration of 1 day is read in accordance with the working-times
>>> specified by the custom calendar....thus also applying the correct
>>> number of working hours?
>>>
>>> Have I missed something; is this an "operating characteristic", or
>>> do I have to trick MSP into doing what I would like it to do?
>>>
>>> Thanks for any tips or guidance.
>>>
>>> James. G



Re: Custom Calendars in MSP 2000 by Steve

Steve
Wed Sep 08 17:37:09 CDT 2004

Remember, all durations are stored in minutes. The "hours per day" setting
on the Calendar Options page is only a conversion factor so you can enter
and display durations in units of a "day" without going to the trouble of
converting it to minutes in your head. But a standard "day" is a standard
"day" - you can not define it as 7 hours of 1 resource and 8 hours for
another- 1 "day" of duration will be the same number of hours for all
resources and all calendars. (The number of "days" that corresponds to
Billy Bob's work schedule this week is another matter entirely - if he is a
part-time worker only scheduled for 4 hours a day, he only works 2.5
standard work days for the 5-day week Mon-Fri that he works.) Think about
what it would be like if it were otherwise - I'm estimating how long it will
take to do a task and I decide it will take 3 days FOR A FULL TIME
EQUIVALENT, 8 HOUR PER DAY, person. Now I look around to see who I have to
do it and I find that I only have Billy who works 4 hours a day. Should it
stay at 3 days, or should it go to 6 on the calendar on the wall? I suggest
that if Billy is doing the task, 3 standard work days equals 6 of Billy's
working days. If the definition of the amount of work in a "day" of
duration grew or shrank depending on the calendar of the resource, we
wouldn't be able to make such subsitutions and have the work hours come out
right.

If you really do need a greater level of precision, enter your durations in
hours and be done with it.

--
Steve House [MVP]
MS Project Trainer/Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


"James G" <JamesG@discussions.microsoft.com> wrote in message
news:1A19C91A-9D98-40D9-A396-6EFEA03D0529@microsoft.com...
> Mike,
>
> Thanks for the rapid response. I did set-up all the calendars etc. prior
to
> entering any data...and this is why I'm somewhat perplexed. After having
> visited your web-site, it only confirmed that which I was already doing.
>
> Of course, once I entered the resource's correct "work" for a customised 1
> day task duration, the duration then reduced accordingly. However, I'd
expect
> the duration still to read 1 day, but interpreted as 1 "custom day".
Although
> I'm not too worried about this particular aspect. My main concern still
lies
> in the fact that, despite applying the customised task/resource calendar,
it
> uses the TOC setting to calculate the hrs-per-day. Can you confirm, to the
> best of your knowledge, that if you apply a custom calendar, the task
> duration should start/finish in accordance with those times?
>
> Thanks.
>
> James.G
>
> "Mike Glen" wrote:
>
> > Hi James,
> >
> > Welcome to this Microsoft Project newsgroup :-)
> >
> > Tha answer to your question is Yes. But you must set up all these
> > parameters BEFORE entering any data (perhaps use a template for new
projects
> > see the FAQs). The TOC settings are the defaults that Project uses, but
> > Project will not change what has already been entered. If you change
the
> > TOC with already entered data, you will have to go back through the
tasks
> > and re-enter their Durations - shouldn't take too long as the Durations
are
> > already there - re-entering them will force Project to recalculate as
you go
> > along..
> >
> >
> > You might like to see FAQ Item: 5. Default Working Hours
> >
> > FAQs, companion products and other useful Project information can be
seen at
> > this web address: http://www.mvps.org/project/
> >
> > Hope this helps - please let us know how you get on :-)
> >
> > Mike Glen
> > Project MVP
> > James G wrote:
> > > Let's see if anyone in the world can help me on this one!
> > >
> > > I've been using MSP for several years now (currently on MSP
> > > 200)...and I hope that I'll explain my predicament succinctly
> > >
> > > I can set-up the calendars, Change Working Time, and custom calendars
> > > without too much difficulty....and I fully understand (I think!) the
> > > settings via Tools/Options/Calendar (TOC)..which sets the definition
> > > of how many hours equals one working day.
> > >
> > > The Problem: If I apply a custom task or resource calendar to that
> > > task, then the start of the task amends in accordance with the custom
> > > calendar (good!), but the duration (therefore the end-date) alters in
> > > accordance with how many hours-per-day have been defined in the TOC
> > > settings, regardless of the working-times set by the custom calendar.
> > > This results in an incorrect number of hours work for the resource,
> > > unless I go into each task and amend the work in accordance with the
> > > true working times of the resource.
> > >
> > > The Example: The basic/project calendar has been set for 06:00 start:
> > > and 18:00 finish, with 12 Hrs-per-day. The basic resources have also
> > > been set in accordance with those times...thus giving a correct 12
> > > hrs work for a 1 day task duration. A custom task and custom resource
> > > calendar has been configured for an 8 hour working day, starting at
> > > 08:00. However, when applying the custom task/resource calendar, the
> > > task finishes at 12:00 on the following day. This indicates that a 1
> > > day task duration equates to 12hrs work, even though a custom
> > > calendar's working day has been defined at 08:00-17:00. This all
> > > seems to come-about because you can define only one set of
> > > Hrs-per-day (in TOC).
> > >
> > > The Question: Is it possible to configure the calendars such that,
> > > when you apply a custom resource/task calendar, the default task
> > > duration of 1 day is read in accordance with the working-times
> > > specified by the custom calendar....thus also applying the correct
> > > number of working hours?
> > >
> > > Have I missed something; is this an "operating characteristic", or do
> > > I have to trick MSP into doing what I would like it to do?
> > >
> > > Thanks for any tips or guidance.
> > >
> > > James. G
> >
> >
> >



Re: Custom Calendars in MSP 2000 by JamesG

JamesG
Thu Sep 09 04:49:01 CDT 2004

Steve/Mike,

Thanks indeed for your replies.......they have been most helpful and have
clarified / confirmed my understanding of how the calendars work.

I appreciate that care needs to be applied when interpreting/applying
durations and work, owing to the fact that 1 day for one person might be 2
days for another. My concern arises when someone reads the programme, and
they are not aware of how the "standard" working day has been defined, and
that the task durations are relative to that "standard" working day.

To make things work in a more intuitive way, thus potentially easier for all
persons involved in producing plans...and interpreting them, my suggestion to
Microsoft would be that, when a custom calendar is applied, the software
reads the start/end times as defined in Change Working Times. I'm pretty sure
that the software could make the very basic calculation that, starting at
09:00 and finishing at 15:00, equates to 6hrs when applying a default
duration of 1 day. Ultimately, as the reader, all you need to know is what
calendar is applied to the task...without having to determine whether the
programmer has correctly defined the hours in accordance with the custom
calendar relative to the "standard" calendar...........or something like that!

I appreciate that there could be number of schools-of-thought on this, and
each method will have it's advantages. But recent situations have prompted me
to clarify my initial experiments with regard to these calendars and how they
affect task durations etc. In conclusion, there is no doubt that there must
be a far better way. We must all remember that the software is here to help
us make our jobs easier; maximising it's sophistication, maximising its user
simplicity......yet minimising its potential for mis-interpretation.

Thanks again, guys.....and I look forward to getting onto my soap-box. In
the meantime, please feel free to initiate some interesting discussions:-)

Regards.

James.G

"Steve House" wrote:

> Remember, all durations are stored in minutes. The "hours per day" setting
> on the Calendar Options page is only a conversion factor so you can enter
> and display durations in units of a "day" without going to the trouble of
> converting it to minutes in your head. But a standard "day" is a standard
> "day" - you can not define it as 7 hours of 1 resource and 8 hours for
> another- 1 "day" of duration will be the same number of hours for all
> resources and all calendars. (The number of "days" that corresponds to
> Billy Bob's work schedule this week is another matter entirely - if he is a
> part-time worker only scheduled for 4 hours a day, he only works 2.5
> standard work days for the 5-day week Mon-Fri that he works.) Think about
> what it would be like if it were otherwise - I'm estimating how long it will
> take to do a task and I decide it will take 3 days FOR A FULL TIME
> EQUIVALENT, 8 HOUR PER DAY, person. Now I look around to see who I have to
> do it and I find that I only have Billy who works 4 hours a day. Should it
> stay at 3 days, or should it go to 6 on the calendar on the wall? I suggest
> that if Billy is doing the task, 3 standard work days equals 6 of Billy's
> working days. If the definition of the amount of work in a "day" of
> duration grew or shrank depending on the calendar of the resource, we
> wouldn't be able to make such subsitutions and have the work hours come out
> right.
>
> If you really do need a greater level of precision, enter your durations in
> hours and be done with it.
>
> --
> Steve House [MVP]
> MS Project Trainer/Consultant
> Visit http://www.mvps.org/project/faqs.htm for the FAQs
>
>
> "James G" <JamesG@discussions.microsoft.com> wrote in message
> news:1A19C91A-9D98-40D9-A396-6EFEA03D0529@microsoft.com...
> > Mike,
> >
> > Thanks for the rapid response. I did set-up all the calendars etc. prior
> to
> > entering any data...and this is why I'm somewhat perplexed. After having
> > visited your web-site, it only confirmed that which I was already doing.
> >
> > Of course, once I entered the resource's correct "work" for a customised 1
> > day task duration, the duration then reduced accordingly. However, I'd
> expect
> > the duration still to read 1 day, but interpreted as 1 "custom day".
> Although
> > I'm not too worried about this particular aspect. My main concern still
> lies
> > in the fact that, despite applying the customised task/resource calendar,
> it
> > uses the TOC setting to calculate the hrs-per-day. Can you confirm, to the
> > best of your knowledge, that if you apply a custom calendar, the task
> > duration should start/finish in accordance with those times?
> >
> > Thanks.
> >
> > James.G
> >
> > "Mike Glen" wrote:
> >
> > > Hi James,
> > >
> > > Welcome to this Microsoft Project newsgroup :-)
> > >
> > > Tha answer to your question is Yes. But you must set up all these
> > > parameters BEFORE entering any data (perhaps use a template for new
> projects
> > > see the FAQs). The TOC settings are the defaults that Project uses, but
> > > Project will not change what has already been entered. If you change
> the
> > > TOC with already entered data, you will have to go back through the
> tasks
> > > and re-enter their Durations - shouldn't take too long as the Durations
> are
> > > already there - re-entering them will force Project to recalculate as
> you go
> > > along..
> > >
> > >
> > > You might like to see FAQ Item: 5. Default Working Hours
> > >
> > > FAQs, companion products and other useful Project information can be
> seen at
> > > this web address: http://www.mvps.org/project/
> > >
> > > Hope this helps - please let us know how you get on :-)
> > >
> > > Mike Glen
> > > Project MVP
> > > James G wrote:
> > > > Let's see if anyone in the world can help me on this one!
> > > >
> > > > I've been using MSP for several years now (currently on MSP
> > > > 200)...and I hope that I'll explain my predicament succinctly
> > > >
> > > > I can set-up the calendars, Change Working Time, and custom calendars
> > > > without too much difficulty....and I fully understand (I think!) the
> > > > settings via Tools/Options/Calendar (TOC)..which sets the definition
> > > > of how many hours equals one working day.
> > > >
> > > > The Problem: If I apply a custom task or resource calendar to that
> > > > task, then the start of the task amends in accordance with the custom
> > > > calendar (good!), but the duration (therefore the end-date) alters in
> > > > accordance with how many hours-per-day have been defined in the TOC
> > > > settings, regardless of the working-times set by the custom calendar.
> > > > This results in an incorrect number of hours work for the resource,
> > > > unless I go into each task and amend the work in accordance with the
> > > > true working times of the resource.
> > > >
> > > > The Example: The basic/project calendar has been set for 06:00 start:
> > > > and 18:00 finish, with 12 Hrs-per-day. The basic resources have also
> > > > been set in accordance with those times...thus giving a correct 12
> > > > hrs work for a 1 day task duration. A custom task and custom resource
> > > > calendar has been configured for an 8 hour working day, starting at
> > > > 08:00. However, when applying the custom task/resource calendar, the
> > > > task finishes at 12:00 on the following day. This indicates that a 1
> > > > day task duration equates to 12hrs work, even though a custom
> > > > calendar's working day has been defined at 08:00-17:00. This all
> > > > seems to come-about because you can define only one set of
> > > > Hrs-per-day (in TOC).
> > > >
> > > > The Question: Is it possible to configure the calendars such that,
> > > > when you apply a custom resource/task calendar, the default task
> > > > duration of 1 day is read in accordance with the working-times
> > > > specified by the custom calendar....thus also applying the correct
> > > > number of working hours?
> > > >
> > > > Have I missed something; is this an "operating characteristic", or do
> > > > I have to trick MSP into doing what I would like it to do?
> > > >
> > > > Thanks for any tips or guidance.
> > > >
> > > > James. G
> > >
> > >
> > >
>
>
>

Re: Custom Calendars in MSP 2000 by Steve

Steve
Thu Sep 09 05:44:22 CDT 2004

Another thing enters the picture and that is the fact that a *duration* day
(or other time interval) and an elapsed *calendar* day are two different
things. Duration time frames - days, weeks, months - only include the days
and hours where work might be scheduled and ignores the times defined in the
calendar as non-working time. Thats why 1 week of duration is 5 days/40
hours, not 7 days/168 hours. The elpased time days recorded on the
calendar posted on your wall, OTOH, are 24-hour intervals and do not pay any
attention to which hours are working and which ones aren't.

In your case you're using a definition of a "day" to be the equivalent of 1
"resource showup" for work, sort of an approximation of elapsed time days.
You're saying, in effect, that if Bill has been on a task Monday, Tuesday,
and Wednesday, he has put in 3 days on the task, regardless of how many
hours per day that represents or the work actually required from start to
finish. Unfortunately that method doesn't allow you to do any real
scheduling or costing on the tasks as you're always comparing apples to
oranges with no consistency through the project. It's pretty much the same
thing as saying an hour for Fred is 60 minutes but an hour for Joe is 30
minutes. If I'm going to estimate that a task is going to require 3-days
to complete, before I know who I'm going to assign to it, I really don't
have a choice but to say that "3-days" should represent the *same* number of
total working *hours* regardless of whether the resource ultimatly assigned
works a 4, 6, 8, or 10 hour workday, if he works an 8 hour day he has to
show up for work three days to finish the task but if he works a 4 hour day
he has to show up on 6 work days before it's done..

Many PMs, BTW, would say that even being able to use the unit "day" at all
when entering durations is only a concession to convenience, maintaining the
best practice is to enter all durations in hours. Some workers prefer not
even to enter durations at all, preferring to work from the resource
assignments screens and defining the man-hours of labour the task will
require, thus letting Project calculate the resulting durations.

Remember durations are ultimately stored and computed using minutes only.

--
Steve House [MVP]
MS Project Trainer/Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


"James G" <JamesG@discussions.microsoft.com> wrote in message
news:0C8D09B3-DFB5-4DAB-8F90-7E3BE1CC30C1@microsoft.com...
> Steve/Mike,
>
> Thanks indeed for your replies.......they have been most helpful and have
> clarified / confirmed my understanding of how the calendars work.
>
> I appreciate that care needs to be applied when interpreting/applying
> durations and work, owing to the fact that 1 day for one person might be 2
> days for another. My concern arises when someone reads the programme, and
> they are not aware of how the "standard" working day has been defined, and
> that the task durations are relative to that "standard" working day.
>
> To make things work in a more intuitive way, thus potentially easier for
all
> persons involved in producing plans...and interpreting them, my suggestion
to
> Microsoft would be that, when a custom calendar is applied, the software
> reads the start/end times as defined in Change Working Times. I'm pretty
sure
> that the software could make the very basic calculation that, starting at
> 09:00 and finishing at 15:00, equates to 6hrs when applying a default
> duration of 1 day. Ultimately, as the reader, all you need to know is what
> calendar is applied to the task...without having to determine whether the
> programmer has correctly defined the hours in accordance with the custom
> calendar relative to the "standard" calendar...........or something like
that!
>
> I appreciate that there could be number of schools-of-thought on this, and
> each method will have it's advantages. But recent situations have prompted
me
> to clarify my initial experiments with regard to these calendars and how
they
> affect task durations etc. In conclusion, there is no doubt that there
must
> be a far better way. We must all remember that the software is here to
help
> us make our jobs easier; maximising it's sophistication, maximising its
user
> simplicity......yet minimising its potential for mis-interpretation.
>
> Thanks again, guys.....and I look forward to getting onto my soap-box. In
> the meantime, please feel free to initiate some interesting discussions:-)
>
> Regards.
>
> James.G
>
> "Steve House" wrote:
>
> > Remember, all durations are stored in minutes. The "hours per day"
setting
> > on the Calendar Options page is only a conversion factor so you can
enter
> > and display durations in units of a "day" without going to the trouble
of
> > converting it to minutes in your head. But a standard "day" is a
standard
> > "day" - you can not define it as 7 hours of 1 resource and 8 hours for
> > another- 1 "day" of duration will be the same number of hours for all
> > resources and all calendars. (The number of "days" that corresponds to
> > Billy Bob's work schedule this week is another matter entirely - if he
is a
> > part-time worker only scheduled for 4 hours a day, he only works 2.5
> > standard work days for the 5-day week Mon-Fri that he works.) Think
about
> > what it would be like if it were otherwise - I'm estimating how long it
will
> > take to do a task and I decide it will take 3 days FOR A FULL TIME
> > EQUIVALENT, 8 HOUR PER DAY, person. Now I look around to see who I have
to
> > do it and I find that I only have Billy who works 4 hours a day. Should
it
> > stay at 3 days, or should it go to 6 on the calendar on the wall? I
suggest
> > that if Billy is doing the task, 3 standard work days equals 6 of
Billy's
> > working days. If the definition of the amount of work in a "day" of
> > duration grew or shrank depending on the calendar of the resource, we
> > wouldn't be able to make such subsitutions and have the work hours come
out
> > right.
> >
> > If you really do need a greater level of precision, enter your durations
in
> > hours and be done with it.
> >
> > --
> > Steve House [MVP]
> > MS Project Trainer/Consultant
> > Visit http://www.mvps.org/project/faqs.htm for the FAQs
> >
> >
> > "James G" <JamesG@discussions.microsoft.com> wrote in message
> > news:1A19C91A-9D98-40D9-A396-6EFEA03D0529@microsoft.com...
> > > Mike,
> > >
> > > Thanks for the rapid response. I did set-up all the calendars etc.
prior
> > to
> > > entering any data...and this is why I'm somewhat perplexed. After
having
> > > visited your web-site, it only confirmed that which I was already
doing.
> > >
> > > Of course, once I entered the resource's correct "work" for a
customised 1
> > > day task duration, the duration then reduced accordingly. However, I'd
> > expect
> > > the duration still to read 1 day, but interpreted as 1 "custom day".
> > Although
> > > I'm not too worried about this particular aspect. My main concern
still
> > lies
> > > in the fact that, despite applying the customised task/resource
calendar,
> > it
> > > uses the TOC setting to calculate the hrs-per-day. Can you confirm, to
the
> > > best of your knowledge, that if you apply a custom calendar, the task
> > > duration should start/finish in accordance with those times?
> > >
> > > Thanks.
> > >
> > > James.G
> > >
> > > "Mike Glen" wrote:
> > >
> > > > Hi James,
> > > >
> > > > Welcome to this Microsoft Project newsgroup :-)
> > > >
> > > > Tha answer to your question is Yes. But you must set up all these
> > > > parameters BEFORE entering any data (perhaps use a template for new
> > projects
> > > > see the FAQs). The TOC settings are the defaults that Project uses,
but
> > > > Project will not change what has already been entered. If you
change
> > the
> > > > TOC with already entered data, you will have to go back through the
> > tasks
> > > > and re-enter their Durations - shouldn't take too long as the
Durations
> > are
> > > > already there - re-entering them will force Project to recalculate
as
> > you go
> > > > along..
> > > >
> > > >
> > > > You might like to see FAQ Item: 5. Default Working Hours
> > > >
> > > > FAQs, companion products and other useful Project information can be
> > seen at
> > > > this web address: http://www.mvps.org/project/
> > > >
> > > > Hope this helps - please let us know how you get on :-)
> > > >
> > > > Mike Glen
> > > > Project MVP
> > > > James G wrote:
> > > > > Let's see if anyone in the world can help me on this one!
> > > > >
> > > > > I've been using MSP for several years now (currently on MSP
> > > > > 200)...and I hope that I'll explain my predicament succinctly
> > > > >
> > > > > I can set-up the calendars, Change Working Time, and custom
calendars
> > > > > without too much difficulty....and I fully understand (I think!)
the
> > > > > settings via Tools/Options/Calendar (TOC)..which sets the
definition
> > > > > of how many hours equals one working day.
> > > > >
> > > > > The Problem: If I apply a custom task or resource calendar to that
> > > > > task, then the start of the task amends in accordance with the
custom
> > > > > calendar (good!), but the duration (therefore the end-date) alters
in
> > > > > accordance with how many hours-per-day have been defined in the
TOC
> > > > > settings, regardless of the working-times set by the custom
calendar.
> > > > > This results in an incorrect number of hours work for the
resource,
> > > > > unless I go into each task and amend the work in accordance with
the
> > > > > true working times of the resource.
> > > > >
> > > > > The Example: The basic/project calendar has been set for 06:00
start:
> > > > > and 18:00 finish, with 12 Hrs-per-day. The basic resources have
also
> > > > > been set in accordance with those times...thus giving a correct 12
> > > > > hrs work for a 1 day task duration. A custom task and custom
resource
> > > > > calendar has been configured for an 8 hour working day, starting
at
> > > > > 08:00. However, when applying the custom task/resource calendar,
the
> > > > > task finishes at 12:00 on the following day. This indicates that a
1
> > > > > day task duration equates to 12hrs work, even though a custom
> > > > > calendar's working day has been defined at 08:00-17:00. This all
> > > > > seems to come-about because you can define only one set of
> > > > > Hrs-per-day (in TOC).
> > > > >
> > > > > The Question: Is it possible to configure the calendars such that,
> > > > > when you apply a custom resource/task calendar, the default task
> > > > > duration of 1 day is read in accordance with the working-times
> > > > > specified by the custom calendar....thus also applying the correct
> > > > > number of working hours?
> > > > >
> > > > > Have I missed something; is this an "operating characteristic", or
do
> > > > > I have to trick MSP into doing what I would like it to do?
> > > > >
> > > > > Thanks for any tips or guidance.
> > > > >
> > > > > James. G
> > > >
> > > >
> > > >
> >
> >
> >



Re: Custom Calendars in MSP 2000 by Mike

Mike
Thu Sep 09 14:38:08 CDT 2004

Hi James,

I have two points to make:

1. If the software were to read the start/finish times from a custom
callendar, which calandar would the software choose when there are multiple
resources assigned each with its own calendar?

2. With proper training on how Project works, you would have had no need to
ask these question in the first place! (Sorry, I don't know whether you
personally have been formally trained - I'm really projecting this to the
general reader)

There are too many out there who acquire Project, expect it to be intuitive
(what's intuitive to one may not be intuitivre to another!) and instantly
say they are Project Managers! Expertise in Project cannot be learned like
Excel or Word, where you can experiment and learn some simple techniques and
produce acceptable results. No, you have to know far more about the
inter-relationships between all the fascets of Project, and this takes
training and experience. This is my favourite beef - not aimed at you in
particular but most of the posters in general! :)


Mike Glen
Project MVP



>>> To make things work in a more intuitive way, thus potentially
>>> easier for all persons involved in producing plans...and
>>> interpreting them, my suggestion to Microsoft would be that, when a
>>> custom calendar is applied, the software reads the start/end times
>>> as defined in Change Working Times. I'm pretty sure that the
>>> software could make the very basic calculation that, starting at
>>> 09:00 and finishing at 15:00, equates to 6hrs when applying a
>>> default duration of 1 day. Ultimately, as the reader, all you need
>>> to know is what calendar is applied to the task...without having to
>>> determine whether the programmer has correctly defined the hours in
>>> accordance with the custom calendar relative to the "standard"
>>> calendar...........or something like that!



Re: Custom Calendars in MSP 2000 by Steve

Steve
Thu Sep 09 16:58:27 CDT 2004

See embedded ....
"James G" <JamesG@discussions.microsoft.com> wrote in message
news:853EAB57-3FEB-4E78-ABFF-3157C7A82563@microsoft.com...
> As you say, Steve, the unit of "day" is a concession to convenience...and
I
> like the way you put that. But as you've probably noticed by the
questions
> on this site, there is an awful lot of confusion about such things!
>
> From a particular perspective; the general principle behind what you say
is
> perfectly sound. Under my particular set of circumstances, though, which
are
> not by any means unique, the software is counter-intuitive, arithmetically
> incorrect (relative to what you believe should have been the result) and
> visually mis-representative, depending upon what side of the fence one is
> sitting.
>
> My colleague is compiling a programm. Two companies are working in
parallel.
> Each company has different working practices. One company does a 12hr day
and
> the other does an 8hr day. We know who is responsible for which
tasks....but
> the project calendar, set under Tools/Options/Calendar is for the 12hr
day.
> My contention is that, during the compilation of the programme, the
> application of a custom task/resource calendar should result in the
> start/finish times in accordance with that calendar.

It does ... if my project calendar says the workday is 08:00-17:00 and I
enter a 1 day task, it initially shows 08:00 as the start time and 17:00 as
the finish. If I now assign it to a resource who happens to work 09:00 -
18:00, the start and finish change to conform to the resource's actual
working hours.

>Going through the
> sequence of data input, here are the results:
>
> 1). Input the task description: The duration defaults to 1 day
(06:00-18:00).
>
> 2). Apply the custom calendar, for an 8 hour day. The duration remains at
1
> day, the custom start-time automatically applies, but the end date changes
to
> 12:00 for the following day. Wow, instantly you have a mental conflict.

Not at all ... Regardless of the calendar in effect, the setting "hours per
day" defines a standard day as being 12 hours. So the duration of the task
is 12 hours. Initially it is on a calendar that is 06:00-18:00 (by the way,
don't your people ever eat? With a 1 hour lunch, 0600-18:00 is an 11 hour
work day, not 12. You *must* deduct the non-working time, including lunch.)
With the initial calendar 12 *working* hours ends at 18:00. But with an 8
hour workday, the 12 hours doesn't end until noon the next day.
>
> 3). Apply a custom resource (assuming a full-time person). The duration
> remains at 1 day, with s/f times as per (2). However, the auto-applied
"work"
> defaults to 12hrs. Wow, another mental breakdown!

Same reasoning as above - the resource works full time on the task, the task
is 12 hours long, thus the work is 12 man-hours.

Think of Startrek. The standard day on the Enterprise is 24 hours, the
Earth standard day, regardless of the actual rotational period of the planet
they are in orbit around. The clocks run on Earth time regardless of where
in the universe they are adventuring. Same thing in project ... we define a
standard day and then all times in the project conform to it. It doesn't
matter what it is but everything else has to be defined in terms of the
standard day. Work hours, OTOH, deal with when peoples clocks at home say
they have to leave for work. That has to be defined in terms of the planet
the guy is coming from, hence the different base and resource calendars.
>
> 4). Manually change the "work" to 8hrs. The duration reduces to 0.67
days,
> the Finish time auto-amends to 17:00. Relief, at last!...only to encounter
> another conflict in that you believe that you had input a "duration" of 1
> working day according to your custom calendar.

No!! You have an even bigger problem! The task requires assembly of 120
widgets and the maximum a human can do is 10 per work hour. The 12 hours
duration is what it will take. Period, end of story. What counts, the only
thing that counts, is getting 120 widgets assembled. Whether you choose to
call the time interval it will take a day, a day and a half, 1/30 of a
month, 2 Floopnies, 12 hours, 6.374 Freebles, or anything else is
irrelevant. If you don't do 120 widgets you haven't done the task. Your
re-definition makes it so now only 80 widgets are assembled so you have not
completed your deliverable. Your project just failed.

>
> In order to achieve the correct result, you have no choice but to manually
> change the "work" on every task. Having spent time configuring custom
> calendars, there is little expectation that you'd have to perform such
manual
> amendments, just to get it to do what you thought you had already done.
Now
> that is cause for confusion!
>
> Ultimately, it's a case of the glass being half-full or half-empty. I
fully
> appreciate that no software is perfect and we all have to work within its
> parameters. I, like all others however, do not like having to explain that
> the software "just doesn't work like that".....especially when you have a
> Director that prefers pencils and crayons.

What you're having a problem with is really not a software issue at all.
It's the imposition of a discipline to the scheduling process that requires
we set some axiomatic definitions of terms and constants at the start of the
process and then require all terms to reference back to that standard set.
It doesn't really matter what you choose to call a "day" but once you make
the decision, *everything* else in the project must use the same definition,
without exception.
--
Steve House [MVP]
MS Project Trainer/Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



Re: Custom Calendars in MSP 2000 by Steve

Steve
Thu Sep 09 17:01:00 CDT 2004

AMEN!! That's why I suggest to people looking for training that they do NOT
look for training in MS Project. Instead they look for training in Project
Management Using MS Project. There is a world of difference!

--
Steve House [MVP]
MS Project Trainer/Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



"Mike Glen" <glenATmvps.org> wrote in message
news:u96xMYqlEHA.3896@TK2MSFTNGP15.phx.gbl...
> Hi James,
>
> I have two points to make:
>
> 1. If the software were to read the start/finish times from a custom
> callendar, which calandar would the software choose when there are
multiple
> resources assigned each with its own calendar?
>
> 2. With proper training on how Project works, you would have had no need
to
> ask these question in the first place! (Sorry, I don't know whether you
> personally have been formally trained - I'm really projecting this to the
> general reader)
>
> There are too many out there who acquire Project, expect it to be
intuitive
> (what's intuitive to one may not be intuitivre to another!) and instantly
> say they are Project Managers! Expertise in Project cannot be learned
like
> Excel or Word, where you can experiment and learn some simple techniques
and
> produce acceptable results. No, you have to know far more about the
> inter-relationships between all the fascets of Project, and this takes
> training and experience. This is my favourite beef - not aimed at you in
> particular but most of the posters in general! :)
>
>
> Mike Glen
> Project MVP
>
>
>
> >>> To make things work in a more intuitive way, thus potentially
> >>> easier for all persons involved in producing plans...and
> >>> interpreting them, my suggestion to Microsoft would be that, when a
> >>> custom calendar is applied, the software reads the start/end times
> >>> as defined in Change Working Times. I'm pretty sure that the
> >>> software could make the very basic calculation that, starting at
> >>> 09:00 and finishing at 15:00, equates to 6hrs when applying a
> >>> default duration of 1 day. Ultimately, as the reader, all you need
> >>> to know is what calendar is applied to the task...without having to
> >>> determine whether the programmer has correctly defined the hours in
> >>> accordance with the custom calendar relative to the "standard"
> >>> calendar...........or something like that!
>
>



Re: Custom Calendars in MSP 2000 by JamesG

JamesG
Fri Sep 10 06:39:02 CDT 2004

Gentlemen, Gentlemen......please forgive me, but I'm grinning from
ear-to-ear.....out of genuine respect for your absolutely brilliant
responses. Methinks a raw nerve has been somewhat tickled....and I cannot but
agree with your sentiments.....although I might leave-out any reference to
Star Trek. Ye Gods, man; I have enough difficulty convincing them that
Velocity * Time = Displacement. However, I think that perhaps the context of
my question has been bypassed.

I think that we have pretty-well established the fact that, regardless of
the application of custom calendars, the "hrs-per-day" setting in the T.O.C.
menu determines the "duration" of the task......therefore the displayed
"duration" and task finish-times become relative to that setting in T.O.C..
All of your arguments have been based around the fact that you've understood
how those calendar-settings interact.....therefore, to you, "it's
obvious".....without the additional complexity of "expectation". The context
of my question, was that there are few people whom are likely to have had the
need to delve into the calendars (among other things) and really make them
operate.....and when they do so, it is definitely not obvious as to how it
works. Moreover, should a non-specialist person read the "conventional" data
on a programme, (generally the Duration, Start/Finish and % Complete/Work
Complete), the ability to mis-interpret the data (thus begin to dis-believe
what it is telling them) becomes all too apparent.

Formal training, being horrifyingly expensive and very limited in its
capacity to convey knowledge, can never compensate for practical experience.
The ops-manuals give only a basic overview of "what it can do"....... rarely
telling you how it does it, how to apply the functionality or the system's
subtleties and nuances. This is why sites, such as this, exist.......and a
good job too! Just look at the questions on Earned Value. The basic
mathematics are very straight-forward....yet MSP 2000 calculates it in a
completely un-conventional manner; thus if you just downloaded the EV curves,
you'd get completely the wrong impression!....and not even know it, unless
you'd had the need/opportunity to delve into the weeds.

I've enjoyed this debate...and please keep up the good work! In conclusion,
though, just think of this question.....a question that nearly everyone can
answer, but very few will ever get right: What is 2+2?
Human convention and expectation defines your starting-point to be zero;
therefore the answer is 4. If, however, nobody tells you the relative
starting-point, the answer you get will always be both wrong and right.

James.G

Steve House" wrote:

> See embedded ....
> "James G" <JamesG@discussions.microsoft.com> wrote in message
> news:853EAB57-3FEB-4E78-ABFF-3157C7A82563@microsoft.com...
> > As you say, Steve, the unit of "day" is a concession to convenience...and
> I
> > like the way you put that. But as you've probably noticed by the
> questions
> > on this site, there is an awful lot of confusion about such things!
> >
> > From a particular perspective; the general principle behind what you say
> is
> > perfectly sound. Under my particular set of circumstances, though, which
> are
> > not by any means unique, the software is counter-intuitive, arithmetically
> > incorrect (relative to what you believe should have been the result) and
> > visually mis-representative, depending upon what side of the fence one is
> > sitting.
> >
> > My colleague is compiling a programm. Two companies are working in
> parallel.
> > Each company has different working practices. One company does a 12hr day
> and
> > the other does an 8hr day. We know who is responsible for which
> tasks....but
> > the project calendar, set under Tools/Options/Calendar is for the 12hr
> day.
> > My contention is that, during the compilation of the programme, the
> > application of a custom task/resource calendar should result in the
> > start/finish times in accordance with that calendar.
>
> It does ... if my project calendar says the workday is 08:00-17:00 and I
> enter a 1 day task, it initially shows 08:00 as the start time and 17:00 as
> the finish. If I now assign it to a resource who happens to work 09:00 -
> 18:00, the start and finish change to conform to the resource's actual
> working hours.
>
> >Going through the
> > sequence of data input, here are the results:
> >
> > 1). Input the task description: The duration defaults to 1 day
> (06:00-18:00).
> >
> > 2). Apply the custom calendar, for an 8 hour day. The duration remains at
> 1
> > day, the custom start-time automatically applies, but the end date changes
> to
> > 12:00 for the following day. Wow, instantly you have a mental conflict.
>
> Not at all ... Regardless of the calendar in effect, the setting "hours per
> day" defines a standard day as being 12 hours. So the duration of the task
> is 12 hours. Initially it is on a calendar that is 06:00-18:00 (by the way,
> don't your people ever eat? With a 1 hour lunch, 0600-18:00 is an 11 hour
> work day, not 12. You *must* deduct the non-working time, including lunch.)
> With the initial calendar 12 *working* hours ends at 18:00. But with an 8
> hour workday, the 12 hours doesn't end until noon the next day.
> >
> > 3). Apply a custom resource (assuming a full-time person). The duration
> > remains at 1 day, with s/f times as per (2). However, the auto-applied
> "work"
> > defaults to 12hrs. Wow, another mental breakdown!
>
> Same reasoning as above - the resource works full time on the task, the task
> is 12 hours long, thus the work is 12 man-hours.
>
> Think of Startrek. The standard day on the Enterprise is 24 hours, the
> Earth standard day, regardless of the actual rotational period of the planet
> they are in orbit around. The clocks run on Earth time regardless of where
> in the universe they are adventuring. Same thing in project ... we define a
> standard day and then all times in the project conform to it. It doesn't
> matter what it is but everything else has to be defined in terms of the
> standard day. Work hours, OTOH, deal with when peoples clocks at home say
> they have to leave for work. That has to be defined in terms of the planet
> the guy is coming from, hence the different base and resource calendars.
> >
> > 4). Manually change the "work" to 8hrs. The duration reduces to 0.67
> days,
> > the Finish time auto-amends to 17:00. Relief, at last!...only to encounter
> > another conflict in that you believe that you had input a "duration" of 1
> > working day according to your custom calendar.
>
> No!! You have an even bigger problem! The task requires assembly of 120
> widgets and the maximum a human can do is 10 per work hour. The 12 hours
> duration is what it will take. Period, end of story. What counts, the only
> thing that counts, is getting 120 widgets assembled. Whether you choose to
> call the time interval it will take a day, a day and a half, 1/30 of a
> month, 2 Floopnies, 12 hours, 6.374 Freebles, or anything else is
> irrelevant. If you don't do 120 widgets you haven't done the task. Your
> re-definition makes it so now only 80 widgets are assembled so you have not
> completed your deliverable. Your project just failed.
>
> >
> > In order to achieve the correct result, you have no choice but to manually
> > change the "work" on every task. Having spent time configuring custom
> > calendars, there is little expectation that you'd have to perform such
> manual
> > amendments, just to get it to do what you thought you had already done.
> Now
> > that is cause for confusion!
> >
> > Ultimately, it's a case of the glass being half-full or half-empty. I
> fully
> > appreciate that no software is perfect and we all have to work within its
> > parameters. I, like all others however, do not like having to explain that
> > the software "just doesn't work like that".....especially when you have a
> > Director that prefers pencils and crayons.
>
> What you're having a problem with is really not a software issue at all.
> It's the imposition of a discipline to the scheduling process that requires
> we set some axiomatic definitions of terms and constants at the start of the
> process and then require all terms to reference back to that standard set.
> It doesn't really matter what you choose to call a "day" but once you make
> the decision, *everything* else in the project must use the same definition,
> without exception.
> --
> Steve House [MVP]
> MS Project Trainer/Consultant
> Visit http://www.mvps.org/project/faqs.htm for the FAQs
>
>
>

Re: Custom Calendars in MSP 2000 by Steve

Steve
Fri Sep 10 08:41:33 CDT 2004

Hmmm 2+2? I used to know that one! Let's see, using the IBM360 in my
basement I get 3.99999999999999999999. And if you liked those Startrek
references, you should sit in on one of my Excel classes where I explain its
Modified Julian Date as the same thing as the Captain's log Stardate but
with a day zero reference of 01 Jan 1900 instead of the date of First
Contact with the Vulcans. LOL

You've said the "hours per day setting ... determines the duration of the
task." Sort of, but not really. The base unit of duration storage and
computation is minutes, without exception. Those three fields in the TOC
page are simply conversion factors for duration entries, allowing one the
option to use the units of days, weeks, and months for duration entries
without having to convert to hours or minutes on your own. Those TOC
entries only function is to allow the convenience of those units for entry
and display and don't "determine" anything at all. (Default Start and
Finish don't determine anything in the working time calendars either, but
that's another issue.)

Interesting comments on how a non-expert should interpret Project's data and
what their expectations might be. Project is, IMHO, a horse of a different
colour when compared to other Office apps in that you don't need to be a
professional writer to know just about verything there is to know about MS
Word, for example. But that's not true with Project and you do need to
bring a knowledge base to the job independent of software knowledge to use
it appropriately. I think Project was written fundamentally to be a tool
assisting the decision making process for someone who is using (or trying to
use) the methodologies of formal project managment. The closest thing I've
seen that you can find publically that describes the *why* of the way
Project was designed is the PMBOK from the Project Managment Institute - it
appears Microsoft's design objectives were to come as close as possible to
the principles of CPM and PERT scheduling defined there as the professional
standard (a specification that is now a formal ANSI standards document,
BTW).

I'm curious about your statement that Project computes EV in a
non-conventional manner. There is a great deal of confusion among new users
about the meaning of the % Complete field, many of them thinking it refers
to scheduled work when in fact it refers to duration, but Project's method
is actually correct according to my understanding of the textbooks. And the
same for Earned Value itself - according to my references, Project's
computation method is spot-on with the textbook definitions (see PMBOK). The
only exception, and even this isn't really an exception, is that there are
several ways to compute the Estimate at Completion but Project only uses one
of them, a straight line extension of the BCWP and ACWP curves.

I have to differ with your comment on formal training and its cost. Yes, it
may be a bit pricey in the short term but in terms of ROI it's one of the
most cost effective uses of resources a beginning PM or someone experienced
in PM but new to MS Project can make. I've done a number of MS Project
"bootcamps" that even had some PMP certified senior project managers
enrolled and even they found the sessions worth the time and money. I'd
agree if the course one takes is the typical "software training" course the
relies on the rote learning "push this freakin' button and practice it"
approach (and granted, all too many do) but a decent course that teaches
both the software and how to use it to reflect proper project managment
practices is well worth the investment. (Take a look at the course outlines
on the International Institute of Learning web site, www.iil.com, for some
good examples.)


--
Steve House [MVP]
MS Project Trainer/Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



"James G" <JamesG@discussions.microsoft.com> wrote in message
news:22F5FD99-C2C2-4165-9C66-A2C339143876@microsoft.com...
> Gentlemen, Gentlemen......please forgive me, but I'm grinning from
> ear-to-ear.....out of genuine respect for your absolutely brilliant
> responses. Methinks a raw nerve has been somewhat tickled....and I cannot
but
> agree with your sentiments.....although I might leave-out any reference to
> Star Trek. Ye Gods, man; I have enough difficulty convincing them that
> Velocity * Time = Displacement. However, I think that perhaps the context
of
> my question has been bypassed.
>
> I think that we have pretty-well established the fact that, regardless of
> the application of custom calendars, the "hrs-per-day" setting in the
T.O.C.
> menu determines the "duration" of the task......therefore the displayed
> "duration" and task finish-times become relative to that setting in
T.O.C..
> All of your arguments have been based around the fact that you've
understood
> how those calendar-settings interact.....therefore, to you, "it's
> obvious".....without the additional complexity of "expectation". The
context
> of my question, was that there are few people whom are likely to have had
the
> need to delve into the calendars (among other things) and really make them
> operate.....and when they do so, it is definitely not obvious as to how it
> works. Moreover, should a non-specialist person read the "conventional"
data
> on a programme, (generally the Duration, Start/Finish and % Complete/Work
> Complete), the ability to mis-interpret the data (thus begin to
dis-believe
> what it is telling them) becomes all too apparent.
>
> Formal training, being horrifyingly expensive and very limited in its
> capacity to convey knowledge, can never compensate for practical
experience.
> The ops-manuals give only a basic overview of "what it can do".......
rarely
> telling you how it does it, how to apply the functionality or the system's
> subtleties and nuances. This is why sites, such as this, exist.......and a
> good job too! Just look at the questions on Earned Value. The basic
> mathematics are very straight-forward....yet MSP 2000 calculates it in a
> completely un-conventional manner; thus if you just downloaded the EV
curves,
> you'd get completely the wrong impression!....and not even know it, unless
> you'd had the need/opportunity to delve into the weeds.
>
> I've enjoyed this debate...and please keep up the good work! In
conclusion,
> though, just think of this question.....a question that nearly everyone
can
> answer, but very few will ever get right: What is 2+2?
> Human convention and expectation defines your starting-point to be zero;
> therefore the answer is 4. If, however, nobody tells you the relative
> starting-point, the answer you get will always be both wrong and right.
>
> James.G
>
> Steve House" wrote:
>
> > See embedded ....
> > "James G" <JamesG@discussions.microsoft.com> wrote in message
> > news:853EAB57-3FEB-4E78-ABFF-3157C7A82563@microsoft.com...
> > > As you say, Steve, the unit of "day" is a concession to
convenience...and
> > I
> > > like the way you put that. But as you've probably noticed by the
> > questions
> > > on this site, there is an awful lot of confusion about such things!
> > >
> > > From a particular perspective; the general principle behind what you
say
> > is
> > > perfectly sound. Under my particular set of circumstances, though,
which
> > are
> > > not by any means unique, the software is counter-intuitive,
arithmetically
> > > incorrect (relative to what you believe should have been the result)
and
> > > visually mis-representative, depending upon what side of the fence one
is
> > > sitting.
> > >
> > > My colleague is compiling a programm. Two companies are working in
> > parallel.
> > > Each company has different working practices. One company does a 12hr
day
> > and
> > > the other does an 8hr day. We know who is responsible for which
> > tasks....but
> > > the project calendar, set under Tools/Options/Calendar is for the 12hr
> > day.
> > > My contention is that, during the compilation of the programme, the
> > > application of a custom task/resource calendar should result in the
> > > start/finish times in accordance with that calendar.
> >
> > It does ... if my project calendar says the workday is 08:00-17:00 and I
> > enter a 1 day task, it initially shows 08:00 as the start time and 17:00
as
> > the finish. If I now assign it to a resource who happens to work
09:00 -
> > 18:00, the start and finish change to conform to the resource's actual
> > working hours.
> >