Global projects. Teams in five different time zones. Team members traveling. “We will meet again on the telcon at 5 on Tuesday.”
When? Tuesday your time? my time?
Some of us may have a calendar system that automatically can communicate and translate date/time. Wonderful (and horrible in other ways that we won’t go into here).
Unfortunately, there are still many “opportunities” for confusion. Ok, maybe it’s not the most critical concern, but many of us have lost time and money (and perhaps sanity) by dropping something critical due to a “late” call, or a “missing” deliverable.
So, a couple of things pop up for me. First, I’m seeing projects using some kind of common time. Of course, some organizations have been doing this for a long time. Most familiar might the military use of “Zulu time,” which is related to what we used to call Greenwich mean time (GMT), which is related to the modern UTC (Universal Time – Coordinated). (see http://en.wikipedia.org/wiki/Coordinated_Universal_Time for more info). In fact, I’ve seen a few projects using UTC as their project standard; there is no ambiguity about time.
While I certainly like the benefits of no ambiguity, I think a more subtle but more powerful force may be in play. The use of UTC can be a unifying force; perhaps only symbolically at first, but practically with continued use. Our actions seem to happen just a little bit more as one team. One might note that the People’s Republic of China uses one time for the country.
The second thing that pops up for me is dominance. Whose time is it? Sure, using UTC can be a “neutral” convention. I’m talking more about when we meet together — who has to make more time concessions? Who comes in early, or stays late, or wakes up in the middle of the night? Being on the west coast of the US, I’ve been on lots of projects where we come in early to catch our collegues in Europe, stay a little later to speak with colleagues in eastern Asia, and then (might as well) stay a bit longer to catch up with our collegues in India. I’ve seen some projects rotate timing, so that no team has to “time bend” all the time. Perhaps the most radical, and something I’ve seen just a few times, is to permanently (for the life of the project) adjust what is “normal” so that all teams are scheduled to work in such a way that there is some overlap every working day.
What are you doing in this globally extended project environment?
