Managing An International Remote Development Team
July 15, 2003 Page 3 of 3
What Went Wrong
1. Travel expenses went over budget. While developing The Ire Sequence it was occasionally necessary to visit various remote teams. Often these were routine trips during pre-production and production, but there were also trips made during emergencies.
At any given time we were usually working with at least two remote teams, but the project was not budgeted for so many visits. As a small development team, the rising costs affected us. As a result, we had to forfeit specific assets to meet the schedule, potential hurting the game's quality.
To address the problem, we reduced our travel and began leveraging online methods for communicating, such forums. We also worked with the developer to create a schedule that included regular visits and took emergency travel into account. We also devised methods for solving some potential emergency situations. By doing so, we were able to cut down on costs by booking flights in advance.
Overlooking a full plan dedicated to scheduling and budgeting travel in relation to working with a remote team is a big mistake, as we found out on "The Ire Sequence".
2. Lack of passion. As I said earlier, passion was something we looked for in remote teams. A team that is passionate about playing and developing games will most likely produce the best assets. Those without passion are more than likely to lose interest in the project, lack determination, and fail to put in the hours required to reach its objectives.
While working on The Ire Sequence, we contracted a team that had a strong background in developing remote assets for several moderately successful titles, including Cossacks. When we visited their studio, we met some very intelligent and creative people, some of which had the passion and ability to work at some of the world's greatest games companies. But something we overlooked was the effect of that team's growth and employment searches. Only a month into development, the external project manager left for a larger company and was soon replaced. Soon afterwards their team brought in a new project manager, but we started to feel the effects of a project manager who had no passion for games. While it's true that a non-interested manager can succeed, problems began to arise that hadn't previously.
So we consulted the remote company and reiterated the goals we had set for them, and told them that the project manager had not met our requirements. We tried to keep in mind that while we had the right to demand whatever we wanted in relation to our project, we knew we couldn't tell them how to hire their employees.
It was when the company began to lay off talented workers that we had to draw the line. We told them that we wanted to be consulted about whom they were hiring and removing from their team, but language difficulties became problematic at this point. It was about then that we realized how instrumental a bilingual person on our own team would have been. But we knew it was our fault to have contracted a company that was becoming increasingly interested in web development rather than games (as they told us). As this was our first time working with a remote team, it stung us in ways we hadn't felt before. Yet it gave us the impetus to work with a more professional team, using knowledge and experience we gleaned from our prior problems, and understanding how to prepare for future incidents like this.
In-game screenshot of Ubi Soft's upcoming cel-shaded first person shooter, XIII.
3. Asset management problems. With every game development project, asset management is an important yet potentially difficult subject. During production of The Ire Sequence, we encountered problems while trying to share assets with the remote team. We began by using an old-fashioned method of sharing assets: via standard mail. The first problems that occurred were mailing the wrong assets, wrongly addressing packages and simply not sending the packages. But we also mishandled the assets once they arrived -- some packages were lost and/or went unnoticed for weeks.
We soon turned to developing procedures for handling mailed assets, and developed specific contingency plans for handling such incidents. But it didn't take long before we decided to migrate all of our asset management online. This meant reserving funds to purchase equipment for remote studios to upload assets to via FTP. This system gave us one place to store all our assets. The only problem was the speed at which it took to upload and download assets, some of which updates were gigabytes in size.
During the development of XIII, the remote team used FTP. The only major pain was uploading and downloading a 5-gigabyte file. Using online capabilities, it doesn't take long at all to prepare a steady asset system. I suggest using one at all times when working with a remote team.
4. Asset implementation setbacks. Whenever Southend Interactive uploaded their newly updated work, Ubi Soft had to download it and run regulatory checks. They would then compare it to the older versions and take the necessary steps to integrate, for example, new sections of code. There are two problems that can result from this process, which you should take into account if you're considering a similar method:
the amount of time that will be needed to integrate the new assets.
It is likely to take some time and may even become a full-time role
for one of your employees. For example, consider how much time is needed
before a new version can be delivered to the remote team when working
on a game for multiple platforms.
- Make sure to schedule periods when the remote team can work on assets that don't rely on an updated version of the game. For instance, Southend Interactive had to wait at least a few days before their uploaded assets were verified and Ubi Soft sent them a new package with the latest version. During this waiting period, Southend needed to work on other assets, but there were no difficulties because we had foreseen this problem.
5. Over management and under management. Who holds the ultimate control within the contractor-client relationship? The company that signs the paychecks, of course. It's important to initially have unwavering respect for each other, but there are times when it is necessary to step in -- and step out -- in relation to management issues.
For instance, we considered when to travel and when not to. Yes, face-to-face communication is important, yet when is it best to visit? Is it better to schedule travel meetings to assert authority or build relationships? From my experience working on XIII and The Ire Sequence, and talking with others in the industry, I've made a list to help schedule travel and meetings. (The following guidelines do not account for unforeseen emergencies within each phase, of course).
& Travel Priority: Highest.
Scheduling: Plan to travel and conduct meetings regularly.
Typical Reasons To Travel: To create a relationship with the remote team. You need to ensure that the contractor understands your project's scope and design. Meetings should be used to plan the best and most efficient methods to achieve your goals. Pre-production could be, and in some cases should be, the longest period of development. Consequently, people should be as ready for a significant number of meetings during this period.
Full Production Phase:
& Travel Priority: Average
Scheduling: Moderate amount of travel as circumstances warrant.
Typical Reasons To Travel: To make sure everything is running smoothly. At this stage you are working with the remote team's project manager to analyze the development schedule and any risks involved. You should also travel to help get the contractor (including the project manager, if necessary) back on track when development is lagging.
& Travel Priority: Low
Typical Reasons To Travel: To establish the QA process. Try not to schedule too many meetings during this phase; especially ones that involve programmers, since they're working hard to find and fix bugs and it's better not to have an employer looking over their shoulder.
The importance of meetings at each major phase.
The Bottom Line
Using international remote teams can potentially provide a fresh cultural prospective on your game's development, you can discover amazing talent in far-off countries, and it can be cheaper than hiring new internal staff. Both XIII and The Ire Sequence were able to draw from pool of talent at a lower cost, and saw no adverse effects in their quality. If you can source a team that's skilled and ready to work to your standards, you should seriously that option. It won't be long until more companies appreciate the potential of international outsourcing and leverage it.
Page 3 of 3