Custom Calendars in MSP 2000

[James G]

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

 

[Mike Glen]

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

 

[Mike Glen]

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

 

[Steve House]

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.

 

[James G]

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]

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

 

[Mike Glen]

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

 

[Steve House]

See embedded ....

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]

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!

 

[James G]

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]

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]

Yes, the definition of "hours per day" does in fact determine the hours,
hence minutes, that are stored as the duration when one enters the unit of 1
working day. But the number of hours in a user-defined standard working day
is a global definition for the project as a whole and does not vary on a
resource by resource basis. The resource's work calendar DOES determine how
many elapsed time days will pass in consuming one standard work day, for
instance it takes 2 of his working days for a part time employee working 4
hours per day to do the amount of work that requires 1 standard day of
duration to complete. The key here is the definition of duration - "the
number of working time minutes, as defined by the governing calendar,
between the point where work is first performed on a task and the point when
it is completed."

One could say that there really is no such measure as a "work day" as a unit
of duration where there is more than one definition of a work day. It is
meaningless to try to specify durations in that sort of variable work day if
the length of the day varies from resource to resource, a "day" of work
being 6 man-hours for Joe, 8 man-hours for Susie, and 10 man-hours for Fred.
You CAN say (and Project does say) that when they come to work on Monday and
work until they go home at the end of the day Joe accomplishes .75 "day" of
work, Susie does 1 "day", and Fred does 1.25 "days" respectively but the
equation of 1 "day" meaning "X working hours," regardless of the number of
regular civil calendar days it takes to do those X hours, must be consistent
across all the resources.

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