Human challenges of multi-location projects

Abstract

Virtual project teams have become more common recently, particularly in the IT industry. In addition, there are more active generations of professionals in the workplace than ever before; each has different values, work styles, and communications usage, which only adds to the challenges.

Although collaboration technology is essential for the management of multi-location projects, success also depends on strong attention to the human challenges. These challenges are reviewed in this paper, which also highlights opportunities for some quick wins in the virtual team environment.

The topics covered are:

• What is a Project? This basic question is revisited in the context of the evolution of the working environment since project management has emerged as a discipline.
• Multi-Location Project Working Methods. This section reports on some examples illustrating multi-location working.
• Human Challenges of Multi-Location Projects, where the specific “challenges” compared with co-location are identified.
• Priorities and Tips for Multi-Location Projects, based on the author's own experience.
• Conclusion.

The author draws mainly on his experience as an international project management consultant, a research project at the ETH Zürich (Swiss Federal Institute of Technology Zurich), and six virtual teams he established as Vice President of Education and Certifications of the Switzerland Chapter of Project Management Institute (PMI).

What is a Project?

All readers of this presentation will be familiar with the description of a project as a “temporary endeavour undertaken to create a unique product, service or result” (PMI, 2008, p. 5). The “unique … result” characteristic means that at least some of the planning and implementation are also unique. The greater the level of innovation, the greater the work needed to define and implement all the details. At the other end of the spectrum, projects similar to many previous ones almost merge from “project” into “process,” because a diminishing proportion of detail is unique and a greater proportion is repetitive.

The “temporary” characteristic implies that the work continues until client acceptance. Traditionally, the client was expected to know in advance what was required, so the definition of a successful project was one that met the [scope] requirements and within the agreed on limits of time and money.

In branches where the deliverables can be adjusted later in the cycle with proportionately moderate effort, the requirements definition becomes a significant project phase, rather than something that is finalized before the project starts. IT projects are a very common example of this type, in which the final product specification is not finally fixed until long after the project has started.

The emphasis on a full requirements definition, followed by full implementation, corresponds to the communications environment, which prevailed at the time the Critical Path and PERT methods were first documented in the late 1950s. In those days, for example, a prototype would be completed in one factory, before being sent to the next location for manufacturing. The comparatively limited types of communication of that era, and the delays and cost resulting from rework, resulted in a strong emphasis on completion, before feeding a deliverable to the next stage.

This is illustrated by an environment where, during the 1970s, the author worked in a factory in Ireland, which was part of a division of an old American company. The prototypes were checked out at the divisional headquarters in Ohio, USA. Transatlantic telephones were expensive in the 1970s and there was only one email address for the entire factory; as a result, there was usually only one round of feedback, sometimes several weeks after sending the prototype.

Acceptance of a leaner approach is incorporated in the “crashing” and “fast tracking” methods for accelerating project delivery times by compromising (e.g., on cost). Improved communications make it easier (e.g., to negotiate deviations from the original plan), which results in optimized (i.e., faster) project delivery dates.

Today, the communication environment has advanced enormously since this situation and is reflected in project management tools of a fundamentally different nature, such as Pivotal Tracker (Pivotal Tracker, 2012), which is story based and supports an agile approach. It also includes “collaboration” and “social” features, as well as RSS feeds, while avoiding, bar charts, for example.

Additional radical developments, which significantly affect the project communications environment and corresponding assumptions include:

• Widespread access to broadband Internet facilities. As recently as 2008, a house move within Canton Zürich, the most populous region in Switzerland, challenged all cable operators to provide broadband access for the author.
• Extensive access to broadband through Wi-Fi technology. Previously, access to the Internet depended on access to Ethernet (not always available to visiting consultants, whose computers are not allowed to log on to client company networks) or even different telephone jacks in each country. Now it is free, for example, in all Tango (modern) trams in Baselland, Switzerland (BLT, 2012).
• iPads and smartphones, which facilitate rapid mouse-free graphic access to data services from any location, eliminating the need to carry extensive documentation (e.g., in a vehicle repair workshop while carrying out maintenance tasks).
• Cloud computing, making it possible to outsource the computing infrastructure while improving the accessibility reliability.
• SaaS software as a service, reducing the cost threshold for services offered.

Although this is no surprise to readers, it is a substantial range of recent innovations, which are relevant to project management, without even referring to some of the other relevant technologies, such as:

• Technologies, which were introduced earlier but still some time after the original description of project management (e.g., mobile telephony and object-oriented programming).
• Technologies with potential applications to project management (e.g., Twitter for broadcasting messages to project team members in real time, or wikis and internet servers, accessible via a browser.

Taken together, it is not surprising that a significant shift is emerging in project management, because the original assumptions about communications have been totally bypassed.

Multi-Location Project Working Methods

At the beginning of the industrial revolution much production was carried out at home: spinning for the cloth industry (e.g., in Scotland) or watch making (e.g., in Switzerland). The distribution and transport of the finished product were organized by entrepreneurs, who often also controlled the supply of raw materials. The social effect was that workers stayed at home with their families. As water, and later steam power, were used, the work migrated to factories. Since then, industrial jobs have been synonymous with “going to work.”

Much more recently, the trend has been reversing (e.g., each executive agency of the U.S. Federal Government is required to establish and implement a policy under which employees shall be authorized to telework (Govtrack.us 2010). The term “teleworking” implies that the individual works directly with the center. There may be some communication with other colleagues who are not in the office, but the basic assumption is that the office does exist.

There are recent reports of a fundamental shift, in which “the office” is either no longer present or merely a place where a minority of contacts and work take place. Two examples are IBM Germany (Spiegel Online, 2012) and the London Symphony Orchestra (BBC News, 2012).

In the IBM case, the employment contracts of the employees are being replaced by project assignments without a long-term engagement. The workers receive international contracts, specifically to circumvent restrictive practices in their home countries. This suggests that the experts would therefore either have a range of other possibly independent assignments or work part-time, depending on personal preference and availability. In addition, the assumption that the workers are in Germany no longer applies; they could be German speakers in another country (e.g., Austria).

The London Symphony Orchestra example is different, because the employment contracts are not changed, only the arrangements for communications and working space. The opportunity to make a fundamental change to the working philosophy was the need to upgrade the telephone network. Travel is an integral part of the work of the support team, who are away from their desks as much as three quarters of the time, and costs were saved by eliminating ISDN telephone lines.

Where project team members work is also changing. With the widespread introduction of Wi-Fi, workers congregate in any place where Wi-Fi is available—from airport lounges to coffee shops or even at home. They appreciate the company of others, even if they are not working with their neighbors.

An option called “co-working” has also developed, where offices for knowledge workers are provided as a step above public places such as restaurants. The organisation often also has a membership so that there is some social control of who is present and there is also the advantage of networking with other like-minded persons. This is particularly common in the United States and Germany and makes it easier for experts to take assignments, for example with IBM, as described above.

The Human Challenges of Multi-Location Projects

The most significant human challenges experienced by the author in multi-location projects are in the areas of management acceptance and teambuilding:

Management Acceptance

In the traditional office, the manager can see how his or her team is working and can intervene at any time to clarify, share information, direct, or support. If the team is not visible or reachable at all times and the trust has not been cultivated yet, management can be reluctant to shift to multi-location working, as the following anecdotes suggest:

• It was privately reported that managers at Sun Microsystems tended to refuse permission for home office working, until the system was changed and they had to justify a refusal.
• The organizer of cultural tours for school groups uses mostly telephone and email. His manager requires him to drive to and from the office, a total of about 8 hours, or the equivalent of one working day per week. Technically, he could do all this work at home.
• The author worked in a small consulting company, where the owner resisted the use of VPN access to the server for reasons of “network security.” The effect of this was that all employees had to travel to work, even to reply to emails, even though the company delivered consulting services over a wide geographical area. The network access was being used as a tool to control access to information and to strengthen management's authority.

Teambuilding

It is definitely very difficult to build up a team of people who do not personally know each other. Even companies such as my SQL, which have grown on the basis of virtual teams, report that the original core team consisted of colleagues who knew each other as students. In addition, they hold regular face-to-face meetings in exciting places to support team development, which offsets the cost benefits of not having an office (Widenius, 2011).

The challenges include:

• Non-delivered assignments result in diminished commitment among other team members—unless everybody delivers, nobody does.
• The influence of the “local” manager and events results in diversion of resources or capacity from project work assigned remotely.
• Lack of team spirit and poor morale among members who have never met each other. For example, a colleague appeared to be “out of touch” for a couple of weeks. Later, it emerged that his daughter had been in a serious car crash and communication with the project team was not his highest priority.
• Technical failures (e.g., apparent lack of individual responsiveness). It seemed that emails were not being delivered. The issue was identified as a misspelling of the team member's name (according to French instead of German norms), which was reflected in different versions of his email address. These addresses were then used as usernames for some applications. This resulted in an apparent unwillingness to communicate over a period of several weeks, which was actually due to an implementation fault.
• Lack of familiarity or comfort with the tools, due to either inclination or the generation of the team member (Baby Boomer, Generation X, Generation Y, and so forth).

Priorities and Tips for Multi-Location Projects

As the diversity factors multiply, teambuilding in multi-location projects becomes exponentially more difficult. In addition, probably most of the current workforce has worked in a more traditional environment for most of their working lives and are not used to the change in paradigm. This implies that there is a learning curve for the workforce as a whole, which will possibly taking some more years to achieve or maybe this is an unduly pessimistic view.

Similar changes occurred, for example, when mobile telephones first became widespread. Very often, the first part of every conversation was to state where each person was: “Hello, I am just getting onto the plane…” The author had a colleague who said he could not call him, even by mobile telephone, because the colleague did not know where the author was.

The following list of recommendations is based on the author's personal experiences and is presented in decreasing order of importance (i.e., the most important points come first). Whether these transfer to other team environments is open to discussion.

Emphasize Trust among Team Members

• The highest priority is to actively participate in conversations and to stop all other activities, such as emails, scanning news tickers, and looking around to see who is passing by. This attention sends a very strong trust message to the partner and is one of the most powerful, and easy tips to implement.
• Deliver on promises. For example, if you set a meeting time, stick to it. The other person may have made great efforts to meet the time and will be disappointed if the partner casually cancels or delays. Another example is to deliver a promised item of information: “I will tell you tomorrow if I am coming.” The effects of not living up to the promise are difficult to estimate when we cannot see our partner's environment.
• Instill a culture in which each person is responsible for his or her own working relationships, including ensuring that the requirements are clear. The team is like a crystal structure, where each atom is in equilibrium with its neighbors. Only the person involved can see the local impact of requests and changes, so the emphasis must be on agreeing on what the deliverables are, not on the minutiae of how they will be implemented.
• Authors on [human] networking and sales recommend finding some common factor, such as a shared interest in sports or that both studied at the same university. Multi-location teams need to be given the time and space to develop this familiarity with each other (e.g., unscheduled “coffee pause” time in teleconferences).

Avoid Unnecessary Diversity

Each additional team factor that is not the same for all members increases the difficulty of multi-location working. Of course, it is also an advantage to a team to have diversity, because this brings various viewpoints to the project; however, this must be balanced by sufficient team cohesion. Diversity factors that can be intentionally avoided in the interest of team working include:

• A common team language. There is a difference between being able to read and speak in a foreign language (e.g., English for many people) and being able to write correctly or communicate all nuances and feelings. Selecting one team language in which all are strong reduces misunderstandings.
• Single country. Select residents from as few countries as possible, because they will share such background features as government, major shops, money, public holidays, sports, and so forth.
• Shared legal environment. This facilitates issues such as taxation and contracts, while also simplifying matters if there is a dispute.

Implement Operational Guidelines

This could be described as a written description of team culture. Developing these rules interactively with the team members contributes to teambuilding, while also making cultural assumptions explicit. For example, depending on the language mix, team members may decide to speak to each other as a first step to resolving issues, rather than writing emails. Other points to consider are:

• How quickly are answers to messages expected (Immediately? Today? This week? On weekends?)
• How private are evenings and weekends?
• On which days does the weekend takes place? Whether a religious holiday is on a Friday, Saturday, or Sunday depends on the location and is affected by the predominant religion, as well as history, as does the starting hour of the weekend (In Israel holy days begin the previous evening, in Ireland at midnight, etc).
• Tolerance for out of hours contacts.
• Use of electronic status signs, short messages (e.g., “what are you doing now?”), similes, and so on. The multi-location project team should agree on how these status indicators are to be used.

In a co-located project team, the communication depends strongly on awareness of the presence and the moods of team members, as well as body language. All of these methods depend on the judgment of the person about his or her own mood, not the perception of the colleague, as would apply to co-located teams. For example, a team member may communicate “busy” but somebody else in the same room would describe him or her as “angry.”

Use Business Process Management (BPM)

Use BPM workflows for repetitive activities, to improve the information flow, and facilitate continuous improvement. Recent developments include cloud accessibility of SaaS applications using smartphones. This extends very substantially the range of situations in which BPM can be applied. Sample applications include RunMyProcess (2012) and Questetra (2012).

The potential advantages are very significant, not only for multi-location projects but also for co-located projects and teams:

• The communications overhead when passing tasks from one person to the next takes much less time and the delays can be much shorter than otherwise.
• The documentation of the processes drives improvements.
• Documented processes can be maintained by a continuous improvement approach.
• The know-how of the firm is captured and not dependent on single individuals who may get ill, retire, change jobs, and so forth.
• The team can easily be scaled up (or down), depending on the capacity demand.

Select Tools According to Team Maturity

There is a very wide range of tools to support project communications, such as databases to wikis, voice communications and tracking tools, web conferences, and so forth. The level of complexity should be suited to the maturity of the team. A tool that IT staff find easy may not suit colleagues from a different professional background.

Conclusion

The transition to multi-location project environments took place long ago. Although there are enormous developments in communications (e.g., “social,” “collaboration”), how these are used in project teams is still evolving.

In addition, it is going to taketime for the general workforce to evolve the best practices for managing multi-location projects, taking full advantage of communications developments. It makes sense to recognize this as a learning phase and to experiment with different ways of working. Specific areas to be addressed include:

• Emphasize trust among team members
• Avoid unnecessary diversity
• Implement operational guidelines
• Use Business Process Management (BPM)
• Select tools according to team maturity