Adjusting Calendars for Time Zones

[Dave]

Hi,

I have a project where the project team is made up of
people from the US (East Coast) and India. As such there
is about a 9 1/2 hour difference in Time Zone. That is,
at 8 AM on Monday US EST, its 5:30 PM Monday in India.

What I was hoping to be able to do was to have to base
calendars to apply to the different resources. Each
calendar would be based on that time zone. That way,
when the resource looked at a task on the project plan,
it would represent the actual time/date in their time
zone and they won't have to worry about any conversions.

Is this possible?

For example, I would like to have a task in the US that
runs from say 8am to 1pm on a Tuesday. Then then next
task (Finish to Start dependent upon first) would be
using an India resource. I would like project to know
the working times and Time Zone impacts of the India
Calendar so that the task would start at 8am Wednesday
India time and show up that way in the project.

Using the SAME calendar for each causes the task to start
at 1PM on Tuesday (EST) which is when the India team is
sleeping. Using a Night Shift type of Calendar for India
doesn't quite work either because everything is still
based on US EST time and therefore would show up as
starting on Tuesday at 10:30PM EST (which equates to 8AM
India time).

Right now, I am basically needing to hardcode constraints
(ie can't start until) to manually account for the
differences when needed.

I would appreciate any thoughts on this.

Thank you,

Dave

 

[Steve House]

The only time it seems that such things would matter is when members of the
team are assigned to the same task but why would a worker in India and a
worker in the USA be assigned to the same physical activity? They may be
the same *type* of activity, programming for instance, but it seems to me
that they are separate tasks. The rule of thumb in creating your WBS is a
task is something performed by one resource. A team might assemble several
physical resources to create a needed combined skillset but when I think of
two resources assign to the same task, it means that they are working
together as a team - physically in the same place and during the same
hours - a bricklayer and a laborer who brings him the bricks and mortar he
needs, for example.

Are you actually doing some sort of online remote team activity, perhaps
using something like NetMeeting, where the two resources are working on the
same object simultaneously in some sort of virtual workplace? Working on
some online real-time collaborative activity? That's about the only
situation I can think of where synchronization across time zones might
actually become an issue. Otherwise who cares if the guy in India and the
guy in the USA start at the same moment?

 

[Dale Howard]

Dave --

Because of the 9.5 hours of difference in time zones between your US and
India team members, and if you track everything using EST, you essentially
have is a "night shift" crew in India and a "day shift" crew in the US. If
your India crew works 8:00 AM - 5:00 PM India time, they are actually
working 10:30 PM (the night before) through 7:30 AM when measured using
Eastern time. That probably works to your benefit, especially if the two
crews are developing software or something like that with shared tasks,
since the India crew can work a full shift and then turn the work over to
their US counterparts.

Because of this situation, you might try creating two Base Calendars in the
Enterprise Global to model this schedule. The India calendar would show
work from 10:30 PM - 7:30 AM, and the US calendar would show work from 8:00
AM - 5:00 PM. Set the appropriate calendar for each resource in your
Enterprise Resource Pool. Because everything is being tracking on US
Eastern time zone, set the Project Calendar for each project using the US
calendar. When you assign resources from India or resources from the US to
a task, their resource calendars would govern the final scheduling of that
task. It's just an idea. You might try it out and see if it helps. Please
let me know if and how this works.

 

[Dave]

Dale,

I tried to do something like this and yes it can get
somewhat towards what I am looking for but not quite.
What I was hoping to do was have the schedule be smart
enought to hop back and forth between time zones rather
than having it all in one time zone. That is, when
someone in India sees a Monday 8 am task with an India
resource attached to it I wanted it to be interpreted as
Monday 8am India time not 5:30pm EST. And then the next
task which would be dependent on that task would be a US
task which could also be an 8am task but this time I
wanted it to be US EST time. It would look kind of weird
in the project plan - ie two tasks dependent upon each
other but both starting at 8am - but if everyone
understood that they could interpret it within their own
time zone it would work well.

Without this, I have to either put hard 'start no
earlier' constraints in the plan or artificially add some
variable number of hours to the duration or dependency in
order to ensure the next task starts at 8am local time.
What I mean by this, is if a task in the US ends at 1pm,
a straight dependency would have the next India task
starting at 1pm EST which is not possible because they
are sleeping! So I either have to add some number of
hours to the task or add a constraint to the India task.
Sorry to run on but I just wanted to be sure I explained
things exactly as my issue is.

Any other thoughts would definitely be appreciated.

Dave

 

[Steve House]

I don't understand why this is an issue. I have the default calendar set as
my project calendar and the resource calendars. I have task A scheduled on
Monday, duration 8 hours. It starts Monday 8 am and finishes Mon at 5 pm.
Linked from it as a successor is task B, linked finish to start. It can
start any time after A finishes, so it could conceivably start at 5:01pm
Monday. But that's non-working time so it is placed in the Calendar on
Tuesday at 8am. We have A assigned to a New York resource and B to a
resource in India. The New Yorker starts at 8am Monday local time in New
York, the Indian starts his task at 8 am Tuesday local time in India, task B
follows A as it should. Even though the Gantt chart shows A finishing at 5
and B starting 8 the next day, 15 hours later, because of the time zones
it's really 30 minutes later.

Here's another thought. Tasks adhere to the resource calendar once
resources are assigned. Borrow from the military, aviation, and
international broadcasting and standardize on UTC as the time zone for all
operational references and calendars. Set up base calendars showing hours
of work in UTC. So if Mr Jones in New York works 8-5 local time, his
calendar shows hours of work as 12:00-16:00 Z and17:00-21:00 Z. Mr Singh in
India who also works 8-5 local has a resource calendar that shows hours of
work as 01:30-05:30 Z and 06:30-10:30Z. Put clocks set to Zulu time on the
wall in both offices <grin>. That's not so far-fetched - I like to listen to
shortwave radio and the wall over my desk has two 24 hour clocks, one set to
EST and the other to UTC - drives my wife crazy when she wants to know what
time it is LOL. Plus I'm a student pilot and my watch shows both local and
UTC because so many things in aviation - weather reports, ATIS broadcasts,
clearance times, etc - are in UTC rather than local. Outlook allows for
multiple time zones to be displayed on their calendars - set them to show
Zulu time alongside the local time for convenience. You get used to it all
very quickly.

I do really wonder why it is so important though. The project schedule is
not intended to micromanage the resource's work days. Seriously, does it
really MATTER if the guy in India starts at exactly 17:30 New York time?
What if he's stuck in traffic that day and gets into the office an hour
late, will the project collapse? There certainly are situations, like Space
Shuttle launches for example, where physical events in widely separated
geographic areas have to be closely time coordinated but the organizations
such as NASA where that's true usually are already using UTC as their
standard clock, everyone is used to it, and it's not an issue. For the rest
of us, it really doesn't matter all that much and realisitically we
shouldn't worry ourselves trying to manage time frames of less than about a
work day. The schedule shows 8 starts Monday at 8 and B starts Tuedsday at
8 and everyone understands that the times listed always refer to the
resource's own local time. What matters in most projects is that Jones
knows he needs to do his thing on Monday and Singh knows he works on his on
Tuesday, not that Singh is waiting breathless for Jones to finish so he can
start up at the same instant.

 

[Dave]

The issue really comes about because the projects I am
working on are being required to track things and a
detailed level with many hand-offs and work/duration of
hours/task rather than days/task.

So in your example below, both tasks could be 3 hour
tasks. Therefore A would end at 11am EST which with a
finish to start relationship would allow the second task
to start at 11am EST but I am looking for a way for the
schedule to be 'smart' enough to know the next task is in
a different time zone and therefore start at 8am the next
day - Tuesday (which would be the next available working
time). Then Task B would take three hours, putting things
at 11 AM India time. Then I would like Task C to start
at 8am TUESDAY since it would be the next available
working time for EST calendar. Also, I may have a second
task, D, that is ALSO dependent upon Task A (FS) but on
the EST calendar. This I would want to show up as 11 am
Monday start time.

 

[Steve House]

You can only have one time zone in Project, sorry. So the best solution is
to set a standard time zone that all the individual offices and resources
use for scheduling regardless of their local time. If you really, truly
need to coordinate the tasks to the minute, use something like UTC as the
standard time reference for everyone. I'm just surprised that you would
really need to do that - in tracking for progress monitoring and costing it
will be important to know that task A was 3 hours and task B was 6 hours and
B followed A, but generally speaking whether task B actually begins one hour
or 6 hours after task A is inconsequential unless you're someone like NASA
where a tracking station in the Canary Islands has to be online and ready at
the exact minute a rocket is launched from Florida.

Maybe I'm just a cantankerous sort, but I think two questions that don't get
asked anywhere nearly often enough is business is "Does it really matter?
Why?" <LOL>