Multi-country projects--preparing for the unknown
B. Scott Matta, Director, Cambridge Technology Partners
Projects are generally based on a balance between three measurables.
Managing a project that spans several countries requires the Project Manager to be prepared for situations not normally associated with these measurables.
I. Politics (real—i.e., international laws and reporting requirements)
• Rights of Privacy
• Rights of Ownership
II. Corporate Politics
• Titles vs. Duties
• Authority (before, during, and after the project)
III. Event Timing
• Workload Distribution
• Primary vs. Secondary
• Time Zone Contingencies
• Written (Recorded)
• Project Costs
• Project Parameters
Through the course of this paper, I will outline situations surrounding each of these topics, present potential if not actual effects of these situations on project management, and finally possible management techniques to control these effects. Since “an ounce of prevention is worth a pound of cure,” simply being aware of these potential situations may contribute to a successful multi national project.
• Geographical Boundaries
• Mineral Rights
• Physical Assets
ALL projects revolve directly around one or more of these items. Indirectly, a multinational project will probably involve several of them. In the U.S., we count on well-established laws and paten rights to ensure fair play. These types of laws may not be as well established in some countries, and highly established in others. They also tend to change with little notice.
A Project Manager planning on travelling between sites may need to reschedule or cancel flights between countries;
• USA to Nigeria
• Peru to/from Ecuador
• Yemen from Anywhere (other than London or Russia).
At a given time in recent history, the flights listed above were available for booking. Due to security problems, war, and affiliations (respectively) these flights are no longer available. Depending on passport and visa regulations, even rescheduling may become too cumbersome to allow easy commuting.
Germany is one of the most thorough countries regarding the protection of electronic data. The strong labor parties have ensured they maintain control and knowledge of the workforce. Hence, any project involved in the synchronization of resource data between Germany and any other country needs to have proper approvals. The result of not having the approvals in place prior to data migration can result in fines and possibly the restructuring of the data feeds.
France, a premier source of wine for the world, has strict trade laws governing the amount of wine that can be exported. If a local winery decides to create an eCommerce web site to sell their wine over the Internet, these trade laws will need to be incorporated in the design. Though this seems obvious, the reporting requirements and shipping regulations around web commerce are not nearly as well established as the existing order management tools; hence, real-time changes should be expected.
Ideally, a project would be planed around existing laws and regulations. This is often taken for granted in single country projects. Multi-country projects require knowledge of both (or all) countries’ laws. Though international data laws are becoming more stable, it is necessary to be aware of any adverse relationship between the countries in a given project. There are a number of ways to determine this:
• International Business Consultants / Lawyers
• Established Practices
I am not suggesting that the project manager become an international lawyer. I am suggesting that someone be given the task of exploration.
Consulates may be contacted over the phone and by mail. Going to the consulate in person is sometimes worth the extra effort, and occasionally required. They are primarily the source of passport stamps and visa regulations. These are often 24 hour or less affairs, but occasionally there is a week long ordeal involving photos, letters, documents, and approvals. Knowing if paperwork is a matter of hours or days is critical information when team members have to travel between countries.
International Business Consultants / Lawyers should be engaged if the project involves the implementation of an import or export system for goods or data. Once brought into the project, they will require a thorough knowledge of the planned expansion, so training time should be allocated accordingly. When choosing an international business consultant or lawyer, look for individuals with experience in the countries of operation.
The Internet can be the source for finding the consulates, consultants, and lawyers as well as a source of direct information; just don’t count on it to be quick and intuitive. The types of data in question (import/export regulations, specific inter-country business relationships, etc.) are available, but finding and utilizing the data are not usually straightforward. Look for country specific home pages and then focus on the business and education sections within those countries. I‘ve included a list of helpful (?) web sites I‘ve used and/or perused in Appendix A. The countries and governments that really need up-to-the-minute information are usually the countries and governments the furthest behind on the technology bandwagon; hence, useful information of this type is not in easy access.
Often, local resources will have a suspicion or even a direct knowledge of adverse relationships or impending multinational problems. As the project manager, one should solicit, be aware of, and question any comments that relate to potential problems. These problems will often be nothing more than exaggerations or rumors; but by actively pursuing them; the project manager is less likely to be caught off guard.
Depending on the type of project and the level of participation required, the assignment of tasks has to be a coordinated event. Managers in one country may be considered “hands-on” workers in leadership roles. The same manager positions in another country may be strictly “hands-off” supervisors. Though the same tasks may be assigned to each of these roles, the execution and monitoring of these tasks will be very different.
A phased, multi-country project begins with a core team of resources focused on a single country. Following a successful initial phase, the project expands to include two additional countries. A project plan is developed based on the initial rollout, but shortly after the start of Phase 2, the progress of one of the countries is significantly less than the other or the first phase. Granted, this can be due to numerous reasons, but the reason “du jour” is the unavailability of resources. During Phase 1, tasks assigned to a department manager were actually completed by the department manager. These tasks are now being reassigned to subordinate employees that do not have the immediate knowledge or resources necessary for quick completion.
First, within the project plan, assign names to resources. Second, review the project plan, to the task level, with the respective resources. The assignments should be explicit and agreed upon. If additional resources are required, they should be identified prior to phase initiation. The resource related levels of competency should also be investigated, and time adjustments should be made were appropriate.
On a high level: simple coordination of events between countries can be an arduous affair. The level of autonomy of each country should be understood early in the project. An effective “overall” supervisor may exist, but often does not. This warrants the need for early contact and buy-in by each country.
A corporatewide decision is made to utilize a particular software system (HR, Accounting, Inventory Management, etc.). The majority of divisions/departments within the company have agreed that the chosen product is, in fact, the best choice. The division/department in the country currently being implemented does not. Further more, the local IT manager wants to prove the inadequacy of the corporate decision.
In an ideal world, an executive sponsor would exist. This person could simply mandate change decisions, and everyone would follow along. This is not always (or usually) the case. Consensus often needs to be built, and even then, not everyone will agree. Based on the fact that actual experience is a strong argument over hypothetical rhetoric, it is often beneficial to focus on the easy wins first. By implementing countries eager for the change, the project manager ensures good cooperation and honest evaluations throughout the project. After one or two countries have proven the effectiveness of the change, the disgruntled country will find it much more difficult to argue the point.
An argument to the contrary of this would focus on implementing the most difficult countries first, thus capturing the majority of problems, and allowing the easier countries to progress faster with easier projects. I have not seen this methodology work effectively due to several reasons:
1. The initial learning curve is often very steep, and can be developed on the easier projects, thus allowing easier solutions for the more difficult situations later. Addressing the difficult situations while still on the learning curve may greatly diminish the rate of return.
2. The project team will have to address both the expected and the unexpected problems. As this paper is a witness, there can be many unexpected problems; so gaining the leverage (in both resources and time) to address the problems will definitely be easier with the easier implementation.
3. If the country truly does not want the mandated change, unrealistic problems can be generated. Without the knowledge of what is and is not essential, excessive time can be spent resolving issues that would and should never happen.
Different countries offer different ranges of holiday and vacation schedules. There may also be differences in the workweek itself. Besides the obvious discrepancies, workflow processes within the countries may also differ. The Project Manager has to coordinate timing with resources and vendors in each country.
Project plans are created with scheduled site visits and deliverable deadlines based on task timing and leveling assumptions for the country of origin. In many cases, this is not the project’s country of origin, but rather the project management computer program’s country of origin.
One of the first steps of any project management software is to adjust the workweek and holiday schedule. If a project management program is not being used, these times and dates are still recorded on a calendar or in a personal organizer. Marking holidays and workweeks is often taken for granted when working within a single country. When multiple countries are involved, this step should not be overlooked. The best source of this information is the local resources, and though this is an easy to fix situation, it is often overlooked until the last minute.
Multiple time zones will also create an array of situations. A worldwide “simultaneous” project will rarely be operating simultaneously. Work schedule coordination and communication plans should be put in place early to prevent compounding project related problems when they arise.
The rollout of almost any project also involves the need for a new “Help Desk” effort. When the project is simply an expansion of an existing system, the existing help desk may be expected to provide the necessary support. Without proper planning, the support team will not be large enough, nor their work hours long enough to supply proper support.
If the consolidation of systems is the focus of the project, schedules for joint resources also need to be taken into consideration. Some commonly neglected-shared resources are the Help Desk, Database/System Administrators, and Executive Support. Aside from the Executive Support, these can be departments within the company, or third party vendors that may need to be contacted. Assumptions for an initial rollout might imply that these resources are simply on call and easily accessible. This assumption may even initially be true, but for a long-term solution, a detailed support schedule must be planned and communicated to everyone involved. Ideally, this support schedule should be in place for the initial rollout to prevent the users from “learning” ways to circumvent the system. (Once someone has established a direct relationship with the managing DBA, or the CIO, it is difficult to train them to go through a different system to get answers.)
The project and the tasks often determine the decisions of “who will do what” and “where it will be done.” Many of these decisions may seem obvious but closer inspection is often worth the exertion. Availability of personal and personnel resources, mechanical resources, technology, transportation, and even power itself should be explored and verified.
A client-server computer system, designed to track South American human resource data, is being implemented throughout several countries in South America. Each country will require two “client” computers, and the location of the “server” computer(s) is assumed to be in the companies South American Headquarters in Bogota, Columbia. The electric power in Bogota is intermittent, requiring companies to invest in private generators to provide back-up support. If the current generator is already operating at maximum capacity, the additional servers could prove to be a breaking point at which a new generator is required. The cost of the new generator and the time required to receive and install it may be cause for the project to fail.
Knowledge of intermittent anything in a project is generally bad news. Power, telephone service, water, transportation, and human resources can all be considered intermittent to one degree or another. In well-developed countries, these intermittent periods are usually few and far between. In less developed countries, exposure to this type of incongruity may be characteristic. An alternative to the adoption of a new generator in the “EFFECT” described above would be to locate the server in their Miami or Houston office, thus reducing the potential power (and possibly telephone) failures. This solution poses other problems in the way of real and corporate politics; but the sooner the situation is realized and communicated, the sooner a realistic solution can be determined.
A project spanning multiple countries with multiple languages presents an immediate communications problem. In many countries English has been established as a basis for business. In many others, it has not, and translators or equivalent translation time must be included in the project plan.
A project started in Belgium may conduct business easily in English. During a future phased implementation in Italy, the same project is required to conduct meetings and training through a translator. Because this was not considered early in the planning phase, the translator had to be one of the existing team members. This is not an unusual event, but it does put an additional workload on the individual(s) involved.
The determination the project language is usually an unplanned event. Many companies have rules governing the conduct of business, and within these rules often lie the decision as to the project language. A novel point is that these rules often differ for the same company in different countries.
English is often considered the language of business and many business managers, regardless of their country of origin, are very proficient in it. Most projects however, do not involve ONLY the business managers. It would seem the project language should be determined by the language of the majority of the project team or the population affected by the project. As altruistic as this sounds, the reality may be different. Knowledgeable project managers, technicians, or functional resources may not exist with proficiency in the chosen language. Both time and money should be allocated to compensate for any translation that becomes necessary. I have found that when working through a translator, doubling meeting times is a reasonable approximation. If a dedicated translator is hired, this may be somewhat less. If translation is done through the group itself, it can be longer. When enlisting a dedicated translator, look for individuals with experience in the business the project is working in. Many business specific terms may not be translatable, and others may be translatable but are not commonly known.
If the project is NOT conducted in the native tongue, on a personal level, it behooves everyone to express an interest in learning the local culture (including the language). The use of the local language in simple phrases will be recognized and appreciated. Appendix B contains a short collection of useful phrases in English, Spanish, German, and French.
If the project revolves around electronic data, language can create an entirely different problem. Character sets (A, a, B, b, C, c versus Â, â, ß, ÿ, Ç, ç ) may or may not be supported by a single application or platform. Transcription direction can also present another situation (left to right versus top to bottom, versus right to left).
Whether a project involves a computer program or not, multiple character sets can present a problem. When implementing a computer system, utilization of the Unicode character set (32 bit versus 16 bit) means a doubling of the space requirements for data. If Unicode is not sufficient, the system may have to utilize additional servers to support the requirements. When a project involves printing international addresses, the distribution of detailed instructions, or the implementation of new corporate policies, these all need to be presented and printed properly. Automating this process requires knowledge of all of the countries currently and potentially involved.
The utilization of Unicode (a 16 bit character set) has become the standard for multinational projects. Prior eight bit character sets could maintain up to 256 symbols. A sixteen bit based character set can contain up to 65,000 symbols. The Unicode Standard defines codes for characters used in the major languages written today. Scripts include Arabic, Armenian, Bengali, Cyrillic, Devanagari, Georgian, Greek, Gujarati, Gurmukhi, Hebrew, Japanese Kana, Kannada, Lao, Latin, Malayalam, Oriya, Tamil, Telugu, Thai, Tibetan, the complete set of modern Korean Hangul, and a unified set of Chinese/Japanese/Korean (CJK) ideographs. Many more scripts and characters are to be added shortly, including Canadian Syllabics, Cherokee, Ethiopic, additional rare ideographs, Braille, Burmese, Khmer, Sinhala, and Syriac. The Unicode Standard also includes symbols to specify changes in direction when scripts of different directionality are mixed. More information can be obtained by going to the Unicode Home page identified in Appendix A.
Though the implementation of Unicode solves some problems, not all systems can use the Unicode Standard. The identification of older programs, third party vendors, or existing internal interfaces that require an eight-bit character set should be done early in the project. Depending on the circumstances, the programs may have to be changed, or the interface translated.
Project costing is a difficult concern when only a single currency has to be tracked. Depending on the country of origin (or not) an overall project currency should be established, through which all cost control should be triangulated. Without a basis for comparison, overall cost control will be impossible.
Due to a projected multiyear project, consideration was given to relocating primary resources to an office in Brussels. In this example, Brussels is both the European Corporate headquarters and the base station for the project. Brussels is also the primary location for European Community Government Officials. This makes Brussels a very expensive place to live. When other projects relocated individuals in other countries, the relocation was often based on time at location. After the determination and conversion of the cost-of-living adjustments for Brussels, it was decided that relocation for any length of time would be prohibitive for this particular project.
Often the largest cost to a project is the cost of the human resources. If these resources have to be relocated, their respective costs go up. A single resource costing $XX.XX while working and living in the United States, may cost $XX.XX + $TT.TT to allow for travel expenses (T). The same employee may cost $XX.XX + $RR.RR + $CC.CC to allow for relocation (R) and cost-of-living adjustments (C) if they are relocated. This is nothing new. Determining the values for T, R and C will lead to the decision to travel or relocate the resource. The point of this example is that the original values for T, R, and C are not in U.S. $s. A significant effort has to be put forth to determine the local values, and then to convert them. When a project involves several countries and several traveling employees, this becomes a dedicated effort. As a rule, project expenses should be reported in a single currency regardless of the currency of the expense. Without a focused plan, cost overruns are more than likely; they are almost guarantied.
International Business and Trade related web sites.
|Currency Converter||//www.xe.net/ucc||A great currency converter.|
|US Agency for International Development (USAID)||//www.info.usaid.gov||A good site for general international relationships and developments.|
|International Organization for Standardization (ISO)||//www.iso.ch||A listing of ISO members, and standards.|
|International Trade Administration||//www.ita.doc.gov||General information relating to US Exporters.|
|European Community Home Page||//europa.eu.int||General EU information including laws and policies affecting international trade.|
|Japan External Trade Organization (JETRO)||//www.jetro.go.jp/top/index.html||General information on importing into Japan, and investing in Japan.|
|Localization Industry Standards Association||//www.lisa.org||Provides standards for software localization.|
|WWW Virtual Library: International Affairs Resources||//www.etown.edu/vl||A listing of over 1800 links to International Affairs related sites.|
|Unicode Home Page||//www.unicode.org||General and detailed information concerning the Unicode character set.|
The inflation rate in many countries is in itself responsible for weekly (sometimes daily) fluctuations in project costs. These wild inflation rates should be planned for and adjusted accordingly within the project.
Particular countries seem to be plagued with wild inflation fluctuations. Argentina, Israel, and Mexico have all instituted stabilization programs to help slow the changes. Projects internal to these countries are the most susceptible to the changes. When only one part of an overall global project is within a country like these, the overall project costs may not fluctuate, but additional time and effort should be recognized for reworking contracts within these areas.
Though there is little a project manager can do about a country’s inflation, being knowledgeable of the potential can allow for the creation of realistic exit strategies should they be needed. Keeping the project funds in a more stable currency until they are needed can also help control project costs.
Often local vendors will be willing (and eager) to work in foreign (stable) currency, but this should be investigated from a legal point of view.
A project manager cannot utilize more money to change the inflation rate of a country, nor can any amount of quality assurance prevent a citywide telephone system failure. Granted, given a few hundred years, a country’s language may change, but most projects don’t have that kind of time available. These are all situations that need to be recognized if not addressed early in any multinational project. In the resolution of all of these, the most crucial element is facilitating communication. Open lines of communication should be established early and maintained diligently through out the life of the project. The ability and desire of team members to communicate real, as well as potential, situations to the project manager will allow for immediate actions. This is also true for single country implementations; however, fostering the proper ability and desire is a much more dedicated concern when acting across multiple countries.
This is a list of phrases I have found useful at one time or another:
|Good Morning||Buenos dias||Guten Morgen||Bonjour|
|Please||Por favor||Bitte||S'il vous plaît|
|More Beer||Mas cerveza !!||Mehr Bier||Une autre bière|
|Where is the restroom?||Donde esta el labavo ?||Wo sind die toiletten ?||Où sont les toilettes ?|
|I've fallen and I can't get up.||Me caigo y no me puedo levantar||Ich bin gefallen und kann nicht mehr aufstehen||Je suis tombé et je ne peux me relever|
|Here is my money, please don't kill me.||Aqui tienes mi dinero, no me mates.||Hier ist mein geld, bitte töten sie mich nicht||Voici mon argent, ne me tuez pas, s'il vous plaît|
|Which way to the Embassy?||Como puedo llegar a la embajada ??||Wo geht es zur bottschaft lang ?||Quel est le chemin de l'ambassade ?|
Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston,Texas,USA