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.
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.