Tips for Working on International Projects

Given the nature of business and the world today, there is a good chance that you’ve worked on or will work on some global or international projects. Here are some things to keep in mind to make your international/global projects successful; some of them are useful outside of international/global projects.

In the IT business there is more and more work being done around the globe. Aside from working for a global IT company, I have worked on several international/global projects. I’m an American living and working in Germany. I can relate to living and working in the U.S. and I can relate to living and working in Europe.

• Good communication is the foundation for successful projects. This is especially true for international/global projects. Because with more countries and nationalities involved in your project, there is a good chance that English is not the first language. To this end you’ll want to make sure that communication is clear and as easy to understand as possible. Some projects lend themselves to a lot of jargon, it is ok to use if it is generally understood by the team, but you need to be careful in its usage as not all of your project team might be familiar with all the jargon. When communicating (verbally or in written form), jargon and abbreviations need to be identified for those people that don’t know their meaning, at least the first time that they’re used in that communication. Information that should be known be the team should be easily accessible, this can be on a shared drive, web site, or through some program (like Microsoft Shared Point or eRoom).

• Keep your assumptions to zero or to a minimum and make them known. When you think about it, this is common sense but I have often seen people making assumptions that more often than not are not accurate. If it works in the U.S., doesn’t mean that it will work everywhere (I’ll talk more about this later). While you will probably have to make some assumptions, you’ll want to confirm the validity of them before adopting them. This means that you’ll need to find out if it really will work that way in Germany, the U.K., Asia Pacific, Latin America, and other areas that you’re work with. You’ll want to make sure that your assumptions are documented and known by those that need to know them. Depending upon how often things change in your project, your assumptions should be reviewed periodically for their validity.

• The way you do things within your department or organization is not necessarily the way that everyone else does it. While the way things are done from department, organization, and company to company can vary a lot, this is especially true when working on international/global projects. This ties in closely with assumptions. There is a good chance that you’ll be involved in some discussions about how things will or should be done. It is better to not look at this as an argument that you need to win, because more often than not you won’t anyways.

• Things will take longer than you think. This is a good point to remember when putting project schedules together, but in applicable in all parts of life as well. Deadlines and milestones should not be so tight that they become impossible to meet. I have found that there are a lot more bureaucratic and procedural things to deal with in Europe that require longer than many Americans allow time for. This can be the cause of many conflicts within projects. This should be remembered upfront.

• Try to keep translation problems to a minimum. While this is part of communication, it is important to remember that you will probably be working with people who don’t speak English as their first language. Just as there are regional differences in how words are used and what the words mean in the U.S. and differences between what it might mean in the U.K. and the U.S., there is a larger chance that what you’re saying might mean something totally different to someone that speaks English as a second, third, or forth language (or maybe only had a little bit of English way back when). There are also those people that don’t fell comfortable speaking English and therefore might not communicate when they don’t understand or have questions, so it is a good idea to confirm from time to time that there is really a common shared understanding of the more important things.

• Be concerned when people don’t ask questions, especially in teleconferences. At first thought, when nobody is asking questions you would think that everyone understands and doesn’t have any questions. Sometimes this is because the other participants don’t wish to ask questions that the other participants will find stupid. They might also be afraid of embarrassing themselves by asking improperly worded or grammatically incorrect questions, so they don’t ask their question.

• There will be cultural differences. This should be expected and used to your project’s advantage. Sometimes projects (or some of the team members) let this divide the team, when the differences aren’t understood or known. Punctuality means different things in different cultures, ignoring the fact that some people are habitually late. Customs about eating (when, where, what and etc.), the use of alcohol, exchange of gifts (you want to be careful that what you’re doing isn’t seen as a bribe or offensive), and greetings (do you shake hands, bow, and kiss, if you kiss is it a single kiss to men and women or once on each cheek?). I saw a really great commercial a couple of years ago where it was mentioned that in some parts of the world you’re thought of as a terrible guest if you don’t eat everything on your plate (no matter how strange or repulsive it might appear to you) while with another culture if you eat everything on your plate it was considered a challenge to the host to give you something else. While the commercial was a bit over the top it made the point that customs are different and this should to be addressed where needed.

• There will also be a difference in the working styles of people based on culture. This can mean that you have some team members that are very by the book and procedural, some that are more go with the flow, some need to be follow a recipe or a cook book and aren’t able to deviate far from it (if at all). Differences in working styles can result in a lot of conflict and resentment on teams.

• When English is a second language (or third, forth, and etc.), the use and command of it should not be taken as a gauge of that team members intelligence. I have noticed in some telephone conferences that accents and speech patterns can come across as abrupt, when that is not the intention of the speaker at all. This can be the result of difference in the grammar, word usage, and pronunciation between the speaker’s native language and English. Some sounds are harder to make going from one language to another; I’ve noticed that many German speakers have a problem with the “th” sound, while English speakers can have problems with rolling their “r”s in Spanish and so on. Language is a skill that some people are able to master while it comes harder to others. Some of the more technical people can have a problem with English. When people make the attempt to speak and write in English, you should avoid be critical of their grammar and word usage, and speaking abilities unless they specifically ask you to do this, and you need to be careful here because you can easily discourage people when being overly critical. As a rule of thumb, try to ask questions about meaning, if it isn’t clear but be sensitive to being to critical.

• Legal and statutory regulations vary from location to location. With many companies being run from the U.S. they can be often be very focused on the city that houses their world headquarters, this is sometimes overlooked. Because the end effect of breaking one of the local legal or statutory regulations can be quite sever, resulting in large fines, law suits, imprisonment, and/or a bad or damaged image for your company within your locale that could have a huge effect on the profitability and viability of your company, these things should not be overlooked. If your project be procuring items for various locations there are probably tax issue and laws to be considered? If there is waste produced in the production of your product, there are probably some sort of environmental regulations for the disposal of this waste. If you’re producing something that will be sold and shipped to another country there are probably import/export laws to be considered. If a plant or office will be built or leased in another country, there will be local laws that needed to be followed. Outsourcing any part of your projects could fall under all sorts of laws as there is more and more pressure being put on politicians related to this topic.

• There are likely to be privacy (data and otherwise) issues. Europe tends to have more laws in regards to privacy than the U.S. There are some laws limiting where data can be kept about people within certain countries, this often means that this data can’t be housed in the U.S. and needs to be kept in Europe somewhere. There are also laws dealing with names and sensitive information being made available. This might mean that a certain country can’t be provided within data captured in this or that application. With a lot of the data mining that applications can do today, much of the information created can’t legally leave Europe or the country it was produced in. Considering some of the stories that have come out about identity theft and account information being stolen, this might not be such a bad thing.

• You might need to consider workers councils and unions into your planning. While in much of the U.S. there isn’t a need to deal with workers councils and unions, they are a part of life in some parts of the world. You might need an agreement with workers councils and unions to do what your project is intended to do. You’ll probably want to start those discussions as soon as is possible, because they can be lengthy. It is also probably more beneficial to try to work with them as opposed to against them. Try to show them the benefit of project to their members.

• There will be differences in time zones to deal with. This should be near the front of your mind as you go through your day. You should try to avoid scheduling a lot of meetings at bad times for people in later or earlier time zone from yourself. It would be a good idea to use something that shows the time of the various locals that you’re dealing with to keep this in mind. I use Qlock and have different clocks set up for cities in regions that I deal with. I was on a project where someone in the U.S. expected that I would be available at 8 p.m. local time, or whenever he needed me. Sometimes meetings at such times might be necessary but you can destroy teamwork and morale if you’re not careful. If you’re expecting that everyone will adjust their schedules to fit yours, you should probably be willing to reciprocate. It might also be possible that some of your team attends off hour calls from their home. Because a lot of the projects being done are utilizing people in different time zones it might be possible to use the “follow the sun” in getting work done. If you aren’t careful, a lot of time can be wasted. There are times that I have needed something from a colleague in the U.S. and I went home for the night hoping that it would be resolved when I come in the next day, only to find it wasn’t and now this item will drag on at least another day.

• You will need to consider the effect of vacations and differing work weeks. In much of Europe, many countries have more vacations days than is common for much of the U.S. and the work weeks can be considerably shorter. During the summer, it is not uncommon that some project team members might be gone for several weeks at a time. This is a good reason to make sure that key team members have back ups or are working in groups to minimize the impact of them being gone and to eliminate the single points of failure. While many people in the U.S. within a 40 hour workweek (maybe working a lot more hours a week than this), some countries in Europe have 30 some hour workweeks (officially anyways). This needs to be considered when determining the duration of effort needed in your schedules.

• Establish ground rules or rules of engagement. While you don’t really know how things will develop later on, it is good to come up with some basic rules and procedures for how things will work. These can vary depending upon the complexity of your project, but you’ll probably want to address escalation, managing of risk and issues, conflicts between team members, and so on. Your company might have some templates and policies already that only need to be slightly modified. It is good for your team to know what is expected of them and the whole team.

• Feedback needs to be provided. I have found on many projects that a lot of times many things are always getting escalated and they might not have needed to be escalated if they were dealt with early enough by the team members. I like to solve problems with individuals when I have problems, rather than escalating to their manager or management. I believe that this should be the first route for a number or reasons, but the biggest is that I believe it is easier to resolve one to one then to bring in other people. More often than not this can clear things up. I’m not sure if this was a cultural thing or not, but I know in the past someone wasn’t happy with something that I did, so they brought it up to management in that program and because it was a large program I’m not sure how many levels of management it went through before it was discussed with me, but if the point had been raised with me directly I could have made the necessary adjustments rather quickly without involving people unnecessarily and dragging it out. I was told that it was custom for people to do these things through management. This is something that could be part of your ground rules or rules of engagement. Feedback doesn’t have to be only negative. When people are doing well, they should be made aware of this. Your team mate would probably even appreciate it if you passed on your praise to their manager.

• Building team spirit is challenging. Many projects will have a kick-off meeting for the team to get things started. This is good because it gives the team members a chance to get to know who they’ll be working with, if they don’t already know the other team member. This is more challenging when the team is scattered around the globe. Although video conferencing is likely to be used more and more in the future, at the moment there is a dependency on telephone conferences and it is hard to build a team spirit via this medium. If expenses allow it, there should be a least one opportunity for your team members to meet. Maybe the budget won’t allow for the whole project to get together in one location at one time, but it might allow for smaller scale travel, where one team member might be able to fly of take a train to visit another. If you’re on a small project with a short duration and a small budget, it might not even make sense to get the team together in one location, but it does help to build a team cohesiveness and “can do” attitude.

• Suggestions should be encouraged. The wider the experiences of the individual team members the more likely it is that they will have suggestions on how to do things that you might not have considered. Encouraging suggestions can be similar to brainstorming, where you want to encourage a quantity of ideas and you’ll want to judge the quality and viability of the ideas/suggestions at a different time. Handling of suggestions is something else that can be encouraged in your ground rules or rules of engagement.

• Different is different, it doesn’t need to be better or worse. Often time people will latch onto an idea, procedure, or way of doing things and unconsciously adopt it as their own. They will think that their way of doing things is the best and not be willing to look at other ideas or ways of doing things because it might be different than what they have accepted and latched onto. There is a tendency to compare ideas and the way things are done with the preconception of “our idea” or “our procedure”, looking to find which is better or what part is better. While it is sometime possible to adopt new ideas and procedures, some parts of your company might be shackled to “their ideas” and “their procedures” and it might not be possible for them to make the suggested changes. Sometimes there are good reasons for what might at first seem totally absurd, and in fact the absurd might be truly better. There could be historical, cultural, legal, or other reasons behind why things are done the way they are. Sometimes you have to accept different is different without judgment.

• You can make friends around the world. While the main goal of our projects is not to make friends; this can be a positive byproduct if you try to treat others fairly, with respect towards them and the differences that make us unique. If you can work with an open mind, you might find yourself making friends in parts of the world that you never imagined.

While adopting these suggestions won’t guarantee success of your international/global project, it is more likely to push things in that direction. You’re also more likely to enjoy your project(s) and people will like and want to work with you. Maybe it is now time to become involved in that international/global project that you have been considering.

October 15, 2007 is Blog Action Day. On this day all of the participating blogs will write about one topic, this year the topic is the environment. When I last looked there were almost 10,000 blogs signed up to participate with a combined reach of over 7,000,000 people. I think that this is a good example of the power of the internet and the blogging community. You can sign up your blog if you have one and be sure to check out some of the interesting post that will be published on this day.