Introduction – are global projects different?
Why is it that project managers seem to lose their self-control and become glassy-eyed when someone mentions “global projects”? Global projects are surrounded by myths and their project managers often take on an aura of either super human or totally insane! Yet, what is the truth? Are global projects inherently different to other projects? In this paper, the author draws on his personal experience together with that of colleagues within his organisation to identify the key factors that distinguish global projects and to propose practical steps that project managers can take to conquer the myths and avoid becoming a future legend.
Global projects and the PMBOK® Guide
The first question to be addressed is whether A Guide to the Project Management Body of Knowledge (PMBOK®) needs extending to fully cover global projects or is it already sufficient? Are there additional knowledge areas or processes that need adding specifically for global projects?
All the combined experience leads me to the conclusion that the PMBOK® is already exhaustive. It is built on the experience of many, many project managers including those with global experience. There are no “silver bullets” waiting to be discovered.
So what does a project manager have to do to successfully manage a global project? The key differences are not additional knowledge areas but the relative attention given to the existing processes within the knowledge areas and process groups. In addition the project manager has to develop general management skills commensurate with the scale and geographic spread of a global project.
This paper will now focus on the specific process groups that need increased focus and the management skills that are essential for success. They are highlighted in Exhibit 1 using the format adopted for the Mapping Of Project Management Processes to the Process Groups and Knowledge Areas (PMBOK®, 2003, p.38).
Exhibit 1 – Focus areas for Global Projects
Project Communications Management
In this section I will address all the process groups involved in the Project Communications Management knowledge area.
The basics that form the core of good communication are:
- audience
- message
- medium
- frequency
- feedback
This section will highlight aspects that are particular to global projects and need special focus.
Language
In the context of global projects, multi national corporations are responsible for propagating the biggest and most dangerous myth of all. This is that the whole world speaks and writes English (or should that be American) well enough to enable the project to be conducted solely in that single language. This is the view from the top emanating from executives and their narrow view of the world. Yet anyone with any experience of working across countries knows it to be false. Whilst it is just possible that the project steering group and the core project team can survive in a single language, this ignores the needs of the many others who are more remote and less engaged on a day-to-day basis. The following are two significant examples of audience groups where clear communication is essential and that frequently require communication in local language. I am sure that the reader will be able to identify many more from personal experience:
- Users (the end customer) – projects create change and users want to understand what this means for them. Their support and buy-in is often essential for the project to succeed. Even if formal documentation is in English, the use of local language for communication of the project goals and impact together with delivering any necessary training will normally significantly increase the prospect of project success.
- Local technical staff – where there is specific technical documentation that has to be used locally by lower skilled technical staff then failing to communicate it in their local language is asking for trouble.
Culture
The impact of culture on communication is significant. In particular cross-cultural feedback can create misunderstanding. Irrespective of language skills, the use of local language at appropriate times will both create a much more positive environment and ensure improved feedback. It is also important to understand the cultural feedback norms of the people you are working with. For example, in some eastern cultures the concept of “no” does not exist so asking, “do you agree” will not work. Agreement has to be established through a more roundabout and lengthy process – which can be frustrating for western cultures. One of my favourite legends is where the project required site designs to be approved locally by a specified level of management. All documentation was in English. In Japan the design was duly completed by the team together with their customer contacts – all of whose command of English was sufficient. The document was then presented to the manager for approval. His command of English was insufficient for him to fully understand the document.
Whilst in many cultures, a manager faced with the problem would accept the assurance of his staff who were involved in the document creation this was not culturally acceptable in Japan. The manager would not approve a document that he could not personally read and understand thoroughly. It had to be translated.
And so to another legend. In Switzerland I watched two Swiss nationals negotiate with two UK nationals. Over a series of meetings both sides complained that the other failed to live up to the commitments made during the meetings. The problem was that each culture had a different concept of the negotiating process and how agreement was reached and confirmed. The UK culture tends to reserve the right to make “minor improvements” in detail when documenting the decisions. The Swiss culture expects no changes. The learning here is that it is important to match the cultures of negotiating team members as well as their styles.
The global project manager has many resources available to provide input and guidance for dealing with different cultures. This should be actively sought during the planning process and built into the plans:
- His / her own organisation – if you are working for a multi national organisation then contact your local office and speak to both locals and ex-patriots for help and to get their (differing) views. For example: What is the dress code? What is the meeting culture, “body language” and language skills and preferred communication styles?
- If your organisation is not global then your customer's probably is. Use their local offices to ask the same questions
- Governments and trade associations have advice centres to help their national companies – the advice is usually free. Use it!
- The internet
Formality of the communication plan
In small teams, communication can be reasonably informal. The absence of a formal communication plan or formal communication sessions should not be mistaken for a lack of communication. It will be happening. As the team size increases and as the geographic spread widens informal communication will break down. The complexity of the communication matrix can be illustrated using the following mathematical formula that calculates then number of lines of communication for a team size of “n” people.
Number of lines of communication = n(n-1)/2
So, for example if there are 3 people, there are (3x2)/2 = 6/2 = 3 lines of communication
If there are 6 people there are (6x5)/2 = 15 lines of communication
It is easy to see that as the number of team members increase so the complexity of communication increases even faster. When you start adding distance, language and time zone complexities it just compounds the problem. The only way to address this is through adopting a formal approach to communication planning.
I would like to offer a simple, practical example of a formal communication plan. This is shown in Exhibit 2.
Exhibit 2 – A simple communication plan
Even this basic matrix enables the communication deliverables to be clearly identified together with the effort and tools necessary to deliver them. This provides essential input into the resource management planning processes.
Time Zones and related issues
My next legend concerns a project manager who liked to hold a short status review meeting at the end of the week (being a good project manger!). He had an EMEA project so a call around noon CET suited almost everyone. This was arranged for every Friday. The project manager could not understand why a number of his local project managers in certain Middle Eastern countries never attended. Weekends and public holidays are well publicised. A good project manager will recognise and respect these in a manner appropriate to the project and the work to be done.
In many global projects it is common to find a structure where design and build teams are centralised into a few “central” locations. These teams often have the need to support other teams located globally. Which leads us to the next myth – why is it that when a remote team has a problem, others think that it really wants to deal with someone on the other side of the world who has just been woken up in the middle of their night. What seems to happen is that the core team believes that the cost and effort to transfer the knowledge into other time zones cannot be justified so the deliver support from their own team using an “on call” system. This really does not work. Their project team customer expects to deal immediately with someone who is wide-awake and in the office with all the documentation and facilities available. Global teams must invest in transferring knowledge to enable support to be delivered effectively in all necessary time zones.
Authoring
In the UK there are a number of national papers that are classified as “tabloids”. Many years ago I was told by the editor of one of these that they had to employ technical authors to take the articles written by their well educated reporters and re-write them so that they had a reading age of 10. A similar principle applies to documentation that is going to be read by global teams. Employ an experienced technical author to prepare project documents that need to be read and understood by team members using a second language. In particular remove complex words and phrases. I have tried to follow this principle whilst writing this paper.
Planning, Executing and Controlling
In this section I will address Planning, Executing and Controlling Process Groups
Large-scale projects require the same management skills as large-scale organisations. The relative roles of the central and the devolved functions must be understood and clearly defined. This leads me to my final myth – that to successfully manage requires every piece of information to be collated centrally. This is how many project managers naturally behave as they progress from small to large projects. Because in a small project, the project manager is naturally able to “know everything” they see this as a requirement rather than just a natural result of the structure. This is their comfort zone and they try to replicate it. It is very easy to spot when this is happening in a global project. The project processes will require every risk, issue, activity etc. to be documented into a central project administration office (PMO). The global project manager will proudly say that he has hundreds of risks in the risk log and will not have time to manage any of them. Analysis paralysis sets in. The teams around the world will regard the PMO as a bureaucracy that adds no value.
I suggest that there is a golden rule to be followed. All controlling processes should be carried out as close to the point of delivery as possible. The processes should only report to the centre the minimum necessary to establish that the process is effective. There should be clear escalation criteria to ensure that only critical issues and risks are directed upwards. Local teams should be expected to be able to solve local problems, locally. I use the rule that escalation should only occur if either the issue puts the whole project at risk or if the issue lies between two separate sub-projects and thus arbitration is required.
In initiation, the role of the global project manager is to define the procedures for the project management processes at a strategic level with clear definitions of levels of responsibility and escalation; and to then implement these consistently throughout the global project.
Throughout the project, the global project manager must ensure that the procedures continue to be implemented and deal with the appropriate escalations when they occur.
Having set the strategy and implemented the controls, the global project manager has to behave as the CEO. This means creating the environment in which the project teams and members can operate successfully. The skills to do this are not the traditional project management planning and scheduling. They are the “softer” skills more usually associated with “general management”:
- Influencing – necessary both within the project and externally with the line managers and executives of all organisations involved with the project (supplier, customer and third parties)
- Advanced team building
- Advanced negotiating – not just for contracts. In this context negotiating has a strong correlation with influencing.
Running versus managing
I want to finish with a legend about myself. 20 or so years ago I was working as a line manager of a large commercial department that provided sales support. I knew that the sales force thought that the department had never been so good. I was doing a great job. Imagine my surprise when I received an average job appraisal from my manager. I was certainly not happy and pointed out how good the department was. My manager agreed but said that when I was absent from the office a reduction in quality started to be noticed within 3 to 5 days. I was too involved in the day-to-day operation and decision-making. I was running the office, not managing it. As a middle manager, he expected me to be focussed on the 3 to 6 month time frame (just as senior executives should be looking at the future year or years). I think that many project managers can identify with this situation. There is a strong zone of comfort in being in the middle issuing the daily instructions.
Well, this legend has a happy ending. I was lucky to have an exceptional manager who worked with me to create a development plan to enable me to manage, not run. This skill transfers perfectly to projects and is a prime reason why I can now deliver successful global projects.