Managing An International Remote Development Team

As the game industry continues to grow at a phenomenal rate, so too does the desire by people around the world to join the industry. As a result, talent is appearing around the world in the form of international remote contractors.

By definition, an international remote team works in a different country than the internal development team. A benefit for the contractor is that it works where it wants to, possibly benefiting from lower wages than that in the client's country (and passing that value along to the client). For the client, using a remote contractor can bring special technical know-how to the project, an international prospective on the game, and often lower costs than hiring new full-time internal employees.

This article focuses on effectively managing such a team. Managing a remote team in another country is a challenge, yet it has been repeatedly proven that when used correctly, a remote team can be instrumental in hitting project milestones on time and completing the game on budget. The article uses Ubi Soft's upcoming cel-shaded first-person shooter XIII, and a previously cancelled Xbox Live title called The Ire Sequence, as postmortem-style case studies to illustrate the ups and downs of managing remote teams. I also provide information and advice from other sources to support the issues I will relate.

Integral Studios began developing The Ire Sequence in February 2001, and had a 12-month internal project schedule. The limited internal core team was based in Indianapolis, Indiana, and worked in collaboration with multiple remote teams worldwide. Remote locations included the United Kingdom, South Africa, Ukraine, Russia and India. The publisher, due to financial difficulties, eventually cancelled the game, and the assets of the game now belong to a California-based game developer.

Ubi Soft France, the developer of XIII, contracted Southend Interactive in Sweden (the same team that developed the Xbox game Deathrow) to work on some aspects of the game. Working remotely, Southend developed the multiplayer functionality and special effects assets for the game. Southend Interactive's team consists of nine people.

What Went Right

1. Planning our communications. The pinnacle of any project manager's success comes from the three "P"s: planning, planning and planning. It's no different with remote management, though there was one thing that increased the long-term efficiency while in the development of The Ire Sequence: a communications protocol among the teams.

Every project manager is required to be an excellent communicator, but making your voice heard in multiple languages (and holding it at a steady octave) can be tricky when you're separated from a contractor by thousands of miles. That's why it's important to develop a detailed and lengthy communication plan.

During the development of the communications plan for The Ire Sequence, we explained the importance of having a communication hierarchy diagram. The benefit of this diagram let us clearly display who should contact whom in a variety of situations. It's important to be open with your external teams, and by letting them contact specific members of the internal in times of need, they can get the information they need to create the game assets on time and to specification. The benefit of preparing the diagram meant it eliminated the time required to relay technical problems to the right people. Likewise, the people with the answers were only contacted when their expertise was needed. This saved time, since technical questions weren't shuffled around in search of a person to answer them. From a project manager's point of view, enabling specific team members to display their expertise can help nurture the leadership and communication skills of talent. It also meant, in my case, that I didn't have to worry about the team wasting valuable time, nor spending my time sifting through feedback and passing it on to the right person.

On The Ire Sequence, one of the development teams we worked with was based in the Ukraine and only had a limited English vocabulary. So providing this team with a full communications plan in English was of limited value. As required though, we dealt with a project manger who spoke both fluent English and Russian, and we made it his role to translate the entire communications document and pass on to his team. (Note that a professional translator could have done this work, but we lacked the resources.)

We soon found out that this communications document became the team's bible. To a remote team, communication becomes almost the highest priority, just below doing the work itself. Each team member was provided a copy of the communications plan so that everyone knew exactly what to do when they encountered technical problems, design issues, problems with tasks or even basic questions related to the game. This made their ability to develop assets far more efficient, and brought my personal project-management style across the border. It also meant that both the core internal team and external groups ran under the same documentation and generally on same schedule that I set.

It wasn't until a rainy day in July (I was in England at the time) that we truly understood how important the plan had become to the team. The project manager of the Ukrainian team had fallen ill as we headed for a key milestone. As specified in the communication plan, my fallback point of contact was an artist on the team, who spoke good English. While the artist did his best, it was incredibly difficult for me to communicate ideas to the associate producer and rest of the team, and I feared that the team's progress would slow. Yet, when I returned the following morning and the project manager was still sick, I was pleased to discover all of the required assets from the team had been completed. Technical problems still came into our team, sometimes from developers who were handy with a Russian-to-English web translator, sometimes from Ukrainians who could speak some English, and sometimes from Ukrainians who could write English but not speak it. The team as a whole was not phased by the lack of communication while their project manager was sick. They simply followed the translated documents that displayed and described what they should do if the project manager wasn't available.

The communication guidelines continually played a large role in facilitating interactions between teams. It enabled the remote team to do their job under practically any conditions. One of the Ukrainian programmers even mentioned that his team followed the guidelines like a bible, making sure the correct people were contacted, helping everyone with tasks like uploading assets, and so on. He also told me that the communication plan made him feel as though he was part of the entire development team as a whole, since it made him aware of what to do and who to communicate with in any situation. There was a time when I thought that my distance from the Ukrainians would make it difficult to share my vision for the project. But I was wrong - documentation is the key.

	Sketched Logo for cancelled Xbox Live title, The Ire Sequence.

2. Establishing a non-standard working schedule. One of the most common reasons game development companies reject the use of international remote teams is because of the impact it can have on working hours. When a contractor is many time zones away, the time difference can be extremely difficult to handle. On the other hand, some contractor teams don't work until late at night, so even if they are just an hour ahead, their working patterns may disrupt the way your internal team wants to work.

Steve Powers, Senior Game Designer at Ion Storm, has this to say about working with remote contractors and teams:

"When I have worked with virtual employees in the past, some of them have migrated to night-owl hours or worked at off-peak times. This complicates communication when schedules begin to diverge. For example, we would arrive at work in the morning, find that an off-site programmer had checked in broken code, and would not be available to repair it until late in the day. As a result, our local developers would be paralyzed during that workday".

This experience is not uncommon, and illustrates problems that can and do occur when using remote teams. So, how do you solve them? It's simple. As the Chartered Management Institute (http://www.managers.org.uk/institute) suggests, all work performed externally must suit the needs and wants of the internal team -- and that's exactly what you have to insist on in these situations.

As this relates to The Ire Sequence, we needed a team that would adapt to our schedule. This could have meant earlier or later starting times, or even in some cases, normal working hours in preference to off-peak times. A project manager must remember that the subcontracted team must suit the client's needs. You should only take on a remote team that is willing to work to your required specifications.

Fortunately, adaptable teams are much easier to find that you might expect. For example, the core of The Ire Sequence team was based on the East Coast of the United States, and we began working with a team from the United Kingdom. The UK-based team, we understood, enjoyed working at off-peak times and in relation to our internal team, we preferred them to do so as a group. So every day around noon, the British team awoke, had breakfast and got to work at around 3:00 pm -- about 10:00 am for us. Sometimes working odd hours like this can destabilize working habits and inhibit socialization, but the UK team was extremely efficient. Many of them were used to working these hours and were great at communicating with our team. The overlapping work hours meant that even over international distances we could efficiently communicate to solve problems, and neither team was left paralyzed at any point.

Sometimes the remote team doesn't need to adapt to extremely different working hours - small schedules shifts are sufficient. As Daniel Jeppsson, co-founder and lead programmer of Southend Interactive suggests, "Four shared hours [between teams] per day could be enough unless the work itself is closely connected…The remote team should also have their own tasks so communication could be cut down to a minimum." Asking the remote team to start work just an hour or two later is unlikely to be rejected, yet could give both teams more time to communicate on technical issues.

If you can contract a talented remote team that's willing to adapt to your project's needs, you should seriously consider using that team. Conversely, no matter how talented a remote team is, if it is unwilling or unable to accommodate your working hours, it will ultimately affect your schedule for the worse.