It wasn’t that long ago that the world was a much bigger place. In the olden days (about 10 years ago) we didn’t have to think too much 
about the real-time impact of global project teams. The world just isn’t that big anymore.
Collaboration challenges
Modern communications technology means that every team member probably has a mobile phone and the Internet is available virtually everywhere (well, almost) and the collaboration tools for video conferencing and screen sharing are so sophisticated that many people prefer to attend meetings from their desks over getting together in person. But technology gives us the tools to communicate, not the practice.
It’s a pretty common occurrence now that when you are looking at how to have a project team communicate, thinking of what time it is in different parts of the world is essential. Here at HMS we have been working for some time with multiple clients whose users are located all over the planet and we have to accommodate not only access to the users but members of the project team as well.
If you are located in North America’s eastern time zone as HMS Software’s headquarters is, then you may find you need to coordinate meetings where some participants are in different North American locations, some are in Europe, some are in India.
There is no convenient time to meet. Well not convenient for everyone anyway. So to make things work, we all have to be a little flexible.
Project Tracking made easy?
The same challenge carries over to the use of project tracking software like our TimeControl. Getting a weekly timesheet from everyone should be an easy win, right?
Not so much.
First of all, what is the end of the week? In Montreal, New York and Chicago it may be Friday or perhaps Sunday. See? Even in the same time zone we might not agree. Ok, here in North America let’s say Sunday is the end of the week and Saturday and Sunday are the weekend. Monday would be the start of the week.
That’s true everywhere, right?
Sorry, no.
In Saudi Arabia for example, the weekend is Friday and Saturday with Sunday being the beginning of the week. If you’re about to complain, don’t be so quick. Only a few years ago, the weekend was Thursday and Friday with the start of the week being Saturday. In 2013 many countries including Saudi who had Thursday and Friday weekends switched to have more of the week match with other international businesses.
Whew. Problem solved. Kind of.
But when should we collect our weekly timesheets then or update our project status? The question isn’t trivial. One of the things that we define in our project update process is the as-of date for statusing. We look at a progressed barchart and we make numerous assumptions about the data:
- We assume that it was all reviewed and approved.
- We assume that the data is all current; not that some of the data was updated last week and some only a year ago.
- We assume that the data goes together; that the progress of time isn’t jumbled together with the progress of material usage.
- And – we assume that the data has a common status date; that the date we progressed one task is the date we progressed the others.
Ok, it’s kind of overwhelming so far but we haven’t even talked about time zones yet.
Timesheet data for example, is often thought of as real-time data. As people submit their timesheets and they are approved, the data will become instantly available for reporting and exporting to other systems. If that is your goal, then the challenges of what time is it become a heartache.
As you are finishing up your timesheets in New York at 5pm on Friday, it is already 11pm in Paris (depending on daylight savings time). It is midnight in Riyadh, Saudi Arabia. But wait. It’s not even the end of the week in Saudi. They won’t finish their week until 5pm tomorrow at which time it will be noon Saturday for you. At 5pm on Friday it is 7am in Sydney Australia and it is 2am in Bombay India. That’s 2am tomorrow.
Some project managers try to manage this by getting everyone onto their own time. “You’ll need to work in Eastern Time,” they say. Good luck with this. The military has this notion. They work on Zulu time which is Greenwich Mean Time (GMT+0). That’s key for coordinating a military strike from numerous places on the globe and avoids confusion but it’s almost always impossible in practice for a project team.
Is it hopeless?
Well, if your goal is time tracking in real time then it may be theoretically possible but it’s highly impractical. But let’s go back to that list of assumptions for a moment. Is it practical to think of project data as real time data? In some limited aspects perhaps but can you act on a project that has only a fraction of its tasks updated? Probably not. Let’s say that you are looking at a resource management report in which only 80% of your tasks have been updated because 20% of your tasks are still being updated by people in different time zones. Should you act upon the information? Perhaps not.
Project data as a rule is batch data. That is to say, it is data that is grouped into a collection and updated and approved all at the same time. We tend to update a who project or a project’s whole sub-section. We tend to group timesheets for the whole week or the whole day even but we update and approve the whole selection.
If that’s the case for our timesheet selection then perhaps the completion of timesheets for our groups in North America which will be done after those in India but before those from the Middle East will all work out because we can set Monday as the lowest common denominator “start of week” day and use that day to determine if all the data has been collected and start our processing of the data then.
Some tips on working around time zones
Here are a few other commonly used tips for making time zones work in your project:
- Divide and Conquer
If you divide your systems and data into sub-systems in different areas and use consolidation features such as sub-nets in Primavera, Master-Projects in Microsoft Project and Consolidation in our own TimeControl you could have different rules in different systems and consolidate the data into a central source for reporting. There are pluses to this approach such as accommodating each group and their own local rules and minuses such as extra system maintenance and data reconciliation. - Filter, filter, filter
Some systems allow the data to appear divided even though it is not. We do this with TimeControl and other systems do this with their project planning data. - Separate the data
You can separate your project files and let each group work independently. Then instead of managing at the task level, you can manage your sub-project at the project level or at a more summary level approach such as weighted milestones.
Making a successful multi-time-zone project work is mostly about cooperating and understanding that your processes will have to adjust. The world isn’t getting larger anytime soon so managing time zones and non-co-located team members has become a fact of life. You can make this work for you too if you can get your different locations to collaborate on a system that works for you all.
