Larry Traynor shares his experience of the complexities of managing international projects and recommends 12 golden rules for success
My first international assignment was in Cologne, Germany, working for Ford, managing international projects. I had to learn German, and went through the “cultural shock” of moving to a foreign country: feeling isolated, misunderstood, and just sad and depressed, even though I had friends around me. Getting through the language barrier is the beginning of breaking through the cultural barrier, and is, I believe, critical to success in working in and especially in managing international projects.
It is not always possible to speak every language and know every culture involved in multi-centre international projects, but the key point is to understand that each language group/culture has potentially fundamentally different ways of looking at the world and dealing with issues.
Unless one has experienced this insight into “cultural relativity” at first hand, and understood that each perspective is equally valid, one runs the risk of turning into the “ugly American”, believing and acting as if the world were an annexe of the USA. I am not talking just about Americans, of course – any dominant culture can be guilty of this.
The desire to become part of the culture is important both at work and socially. One should create and maintain a good work/social balance with colleagues on a project. The project manager can facilitate this by structuring group project events at outside venues, for instance, where teams from different countries can come together to focus on project issues, but also to share time outside work at meals and appropriate social events.
It is also crucial in my experience, regardless of how good the telecommunications facilities are, to regularly schedule face to face meetings with key project personnel. There is simply no substitute for personal contact, both professionally and socially in building project teams, getting them to work and communicate with one another, maintaining and improving their individual and group performance, and ensuring project success. The project manager must take the lead in this, and show willing to spend the extra time and money on this key ingredient to international project success.
‘Hard’ problems
Another source of complexity in international projects is differences between legal and regulatory regimes across different countries. One example from my recent experience occurred on a so-called “X-Border” project within a Swiss firm, where an existing system from its German arm was being integrated into the Swiss Head Office environment.
The company had outsourced all of its development work to a third party, but hadn’t given much thought to the practical consequences of this regarding development in such a X-Border environment by a third party. They were in the financial services industry and their customer data was subject to special conditions in each country’s Data Protection legislation. This presented the third party developers, and their company led project management with significant operational issues when the third party needed to access customer data in order to develop and test their applications.
In Germany, it turned out that it was totally illegal for the third party to deal with customer data directly in any form that made it even partially recognisable. They had to “scramble” large amounts of customer data in order to make it unrecognisable from the data protection point of view but still usable for development and testing. This cost an additional 2 million Euros, which was outside the budget of the project in question.
No-one knew if it was legal for the German third party developers to access Swiss customer data as part of the same project and if not, whether yet another 2 million Euros would have to be spent to scramble the data.
The matter was pressing, as there was only about 5 months to go for the first implementation and the third party developers were in full swing and required an answer immediately. The lawyers “swung into action” as only lawyers can do, and came back with an answer 3½ months later.
In the meantime, the firm had arranged for access to the Swiss data as if there were no data protection issues, hoping that the right answer would come back from the lawyers. This time the right answer came back, but in such situations there is never any guarantee that such risk taking will prove positive. If it hadn’t, the firm would have been liable for serious financial penalties, but if they had simply waited, they would have entirely missed the deadline for the first production implementation, which was a major corporate event and high on the list of the Board’s strategic priorities.
OODA: Observe, Orient, Decide, Act
An interesting framework for almost any complex activity requiring good decisions and the ability to learn quickly from the environment is John Boyd’s OODA “Loop”.
John Boyd was an aircraft designer and very successful jet fighter pilot. He flew the American F-86, which won 9 out of 10 dog-fight encounters with its rival Mig-15 despite being by all accounts an inferior aircraft.
Boyd pondered over this conundrum, and reviewed in his mind what he did in the cockpit during a dog-fight. He first observed, then oriented himself, planned for action and then acted. Boyd called this process OODA (observe, orient, decide and act). Critically, he performed this sequence over and over again, and presumably his counterpart in the Mig was doing the same thing.
He decided that the primary determinant to winning dogfights was not merely going through the loop better than the other fellow – it was doing so faster. In other words, speed of iteration beats quality of iteration.
So how could the F-86, an inferior aircraft, iterate faster than the Mig? It turns out that the F-86 had a hydraulic flight stick whereas the Mig-15 had a manual flight stick, which became increasingly difficult for the Mig pilot to operate as he became tired from having to push it constantly without hydraulic assistance.
Roger Sessions, a well known specialist in the pragmatic implementation of Enterprise Architectures, has called this “Boyd’s Law of Iteration”: “In analyzing complexity, fast iteration almost always produces better results than in-depth analysis.”
International project management environments tend to be extremely complex and are an ideal place to implement Boyd’s insights. In addition to speed of iteration, in his orientation phase, one of the key components to be taken into account in Boyd’s model is the “cultural conditions” of the observer. It is clear that our own cultural views colour our observation and hence directly affect our decision making process and resulting actions.
My own experience in international project management environments has confirmed this: going through the OODA Loop faster (with due consideration given to the cultural dimensions) in complex situations is preferable to a slower, more thoughtful and perhaps higher quality approach. For example, quickly producing an outline solution, even when you know it is incomplete and not totally accurate, and distributing it to all those whom you believe may be affected, is probably better than not producing anything and working until you know have an absolutely correct solution over a longer period of time. You will need several iterations in any case, and, in the meantime, you will most likely have identified other parties who may need to give input.
This type of behaviour is entirely pragmatic in projects (you must win the dog-fight!), but at the same time, it runs counter to our learned behaviour not to make mistakes. In some countries and companies, it is crucial not to be seen to be making mistakes of any kind, which is a great inhibitor to positive action. It has also been my experience that IT staff in particular are extremely loathe to act in such a fashion, preferring to never issue anything that isn’t perfectly complete. One must have the courage to press on through Boyd’s Loop, take the flak from those who miss the forest for the trees and correct things in successive passes through the Loop.
The Golden Rules for Managing International Projects
In conclusion, my 12 Golden Rules sum up the practical lessons I have learned over my 30 years on managing international projects successfully:
- Don’t be an “Ugly American”: make an effort to walk in the shoes of those affected by your project.
- Encourage face to face meetings for key project leaders and staff in alternating venues in the different countries involved in the international project.
- Work out a language strategy that suits the majority of project members.
- Make an effort to participate in social events of the countries you are working in, and try to schedule a few such events for the key project team members over the course of the project.
- Always be polite. Remember that you are a guest in the country you are working in, and your behaviour will be taken as representative of your own nationality as well as of your person.
- Adjust your professional standards to the culture of the company you are working for, without damaging your integrity. Standards are fine, but don’t attempt to enforce them too rigidly or in a manner you are accustomed to that simply will not work for a particular client.
- When confronted with new dimensions of complexity, consider using John Boyd’s OODA Loop approach: press on quickly, even though you know your first attempt is not complete and not totally accurate. Make corrections in the successive passes through the Loop.
- Remember that project management is all about information and communication. Information becomes harder to get in international projects and communication is made more difficult by the linguistic and cultural differences. No IT package will solve this – there is simply no substitute for keen soft human skills in this area. Don’t get me wrong: I am not an IT Luddite, but the emphasis has to be on sound human communication skills with technology as a support.
- Virtual Project Teams can become a reality if you have something like Microsoft Project EPM installed, which allows sharing of plans over a shared server and over the internet. The technology alone is not enough, however, unless you have the soft skills described earlier and the company involved has provided proper training for their staff and is at a fairly advanced stage of sophistication (as judged by the PMI stages of maturity, for example).
- Find out who has the best intra-company network among your project staff and bind them to yourself with hoops of gold! This person will hold the key to solving all the end-to-end problems which are bound to arise during the course of the project.
- Remember that you are there to do a particular job, but that there will usually be an implicit agenda and terms of reference that will never be written down: you are there to make your boss look good!
- The best tools are common sense, flexibility, a positive attitude, and a commitment to the best motto for every Project Manager: Execution, Delivery, Results!
About the author: Larry Traynor is a Board level senior executive interim manager and management consultant with 38 years’ project experience, including some 30 years of managing international projects. Larry’s career began with the APOLLO Moon Project in 1968 where, as a programmer and analyst, he designed and tested real-time software for the project’s front end telecommunications. After applying his skills in the emerging real-time technology to the finance and retail sectors, he took on his first international assignment working for Ford in Germany as an IBM Database and Network Specialist with European-wide remit.