One of the great things about being part of the globalization team here at Adobe is that we get to work regularly with people around the world, on an on-going basis, as if they are down the hall from us rather than well over the earth’s horizon. It becomes second nature to just know what time it is now in Tokyo, Beijing, Noida, Bucharest, or Brno, all relative to each other. It’s a known fact that if you must to schedule a live meeting with people in North America, East Asia, and Europe, someone will be stuck with a very inconvenient time slot.
These differences in time zones work for and against us, too, when it comes to project schedules, whether handing off files for localization, or delivering the final product. Where you are in the world can be an advantage or disadvantage, depending on where your stakeholders are located.
My main job at Adobe has been program management on the product localization team. That means that I have done my share of project schedule development and maintenance. One of the early lessons I learned being in the business, in this position, is that the details in the schedule matter, especially those that define when a task is supposed to actually happen, or rather, when it should start or be completed.
The schedules that I manage assume that the finish dates associated with any given task is relative to end-of-business-day local time for whomever the task is assigned. For example, if the task “Deliver Translated Files” is scheduled for Tuesday and is assigned to the team in Beijing, they have all day Tuesday, local time, to finish the task. If they are delivering it to a team on the west coast of North America, then they actually have longer than that since there probably won’t be anyone in the office in San Jose to take delivery at 6PM Beijing local time (unless we’re in end-game, crunch time, of course!).
Because my team and I are on the west coast of North America, we realize that having until the very end of the day to get things done cuts into the working day for those folks in East Asia. Therefore, we typically will account for that by adjusting the start date of the subsequent task for the folks in Asia to be their next working day. That adds a bit of flexibility for us since we then have more time to get our task done, which equates to a bit of slack in the schedule in case things don’t go as planned, a not uncommon occurrence.
This strategy seems to work out pretty well. The key is that the details must be laid out explicitly and be well known and understood. I make it a point to discuss this schedule rule exhaustively during kickoff meetings, ensuring that everyone understands. In fact, it is mentioned in the footer of my schedule files, just to be sure it gets proper ongoing visibility.
Certainly, all the details of the project should be well advertised and universally understood to ensure project success and to minimize risk. That’s what good communication among project managers and the projects teams can do for you. But I’ve seen the this time zone caused task deadline confusion trip people up enough to know that it’s important.
Time zones differences can be tough to get used to, especially for those who are new to working with people in various, greatly varied regions. Time zones can help or hurt, provide you with a slight cushion or cut your day short. But if the rules are defined with your teams and stakeholders, geographical differences should not be something that slips you up.
I’d be interested to hear stories about how time zones have helped, hurt, or simply confused. I invite you to leave your experiences in the comments section of this blog post.
International Program Manager
image: flickr user triciawang