Project Management Across Time Zones

Even though I haven’t been working for a global company for all that long, I’ve noticed that a lot of people have difficulties with what seems like a trivial issue: time zones.

My company has offices in the majority of countries, with people in almost every time zone, and it has been that way for years. Even so, most people seem to have difficulty – at least occasionally – correctly accounting for how business is impacted by time zones. Sure, some teams may never care about differences in a work day, especially if the groups are only loosely coupled, but if you have a global team, your project coordination can really suffer if you don’t pay attention.

For me, the most common issue is the lag time for back-and-forth communications. If a group in Tokyo asks a question to a person in Paris and that person responds after lunch (Paris time), that is close to the end of typical work day in Tokyo. All it takes is one or two people coming in late or leaving early – dropping off children, stuck in a meeting, or a doctor’s appointment – and the communication loop will be delayed at least 24 hours. In this more connected world, blackberries, web mail, and iPhones help with after-hours communication but that is not a panacea.

Since time zone lag is unavoidable, clear and complete communication is essential. Wherever possible, you need to “close the loop” to avoid multiple back-and-forth exchanges since each loop might have a delay. What I try to do is:

• Clarity in references: When assigning a task for “end of the day, Tuesday” make sure you explicitly say what end of who's day you mean. “Due to the telephone call with Atlanta, please send me that document before 8pm Tokyo time (1pm Paris time)” is more likely to be understood than “before lunch”. Referencing the other person’s time zone is probably best but if there are multiple locations, using UTC or GMT time is better. When using UTC / GMT time, I tend to use 24-hour / military time for additional clarity. That may just be me, though.
• Clarity with schedule constraints: If there is something that needs be done before an Asia office opens for the day, it should be made clear to people in later time zones. Especially in the IT world, people think that midnight on Sunday is an excellent time for routine maintenance and may not realize that your Asia offices is already open for business on their Monday morning. Combining this with the previous tip, “Make sure that this patch installation is complete at all sites before 23:00 UTC on Sunday, October 23rd, to avoid conflicts with the Tokyo office” would be a good way to tell team members of a schedule constraint.
• Clarity with dependencies: The time lag affects decisions as well. If an office needs to receive a decision from a manager the “early” office in order to work, the “late” office could waste a day, have people sitting idle, or miss deadlines if the manager didn’t know that people are waiting.

No matter how you manage risk, things happen. In a global team, after-hours contact procedures must be included somewhere in your risk response planning. This is even more important in those European countries where after-hours work is strictly controlled and after-hours contact information (phone numbers, pagers, etc.) is strictly controlled by employment law. The last thing you need is to have a major office down for several hours because no one had a phone number for a service provider in Stockholm.

Even the most routine activity - scheduling meetings - is made more difficult. Knowing that Tokyo is in UTC+9 and Seattle is in UTC-8 should just mean some simple math to pick a time, right? Unfortunately, over the past decade, there have been many changes in daylight savings time rules. It can be hard to tell when things change and how that affects your regular meetings. Your calendar scheduling application probably has the correct settings but I think that every global project manager should regularly check with www.timeanddate.com. They have an excellent meeting planner and pretty clear explanations of other time and date related topics.

Even with all the challenges, you can leverage the power of time zones for a project. Having other people working while you sleep can really speed things along and reduce total durations. The key to this, like many project related efforts, depends on communications and collaboration. As long as the work is broken down to easy to manage work packages, there should be a way to hand-off task between teams. If your WBS is really detailed, the hand-off can probably happen with just simple e-mails or status reports but it is likely that some sort of hand-off meeting will be necessary. The time commitment, attendees, and frequency of the hand off meetings will vary a lot but I find that IT related projects need meetings between project managers on a daily or three-per week basis for 15 minutes over the phone at a minimum.

Global project teams can really accomplish a lot if well coordinated. Multiple time zones add complexity but by paying attention to schedule details, you can come out ahead.