Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Outsourcing: A Little Checklist to Save You a Lot of Hassles
arrowPress Releases
January 16, 2022
Games Press
View All     RSS
If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Outsourcing: A Little Checklist to Save You a Lot of Hassles

June 22, 2010 Article Start Page 1 of 3 Next

[Working with outsourcers is a vital part of much game development these days, but it's easy to get off track, and this article from a former development director for 2K Games delves into methods to increase reliability and foster communication.]

In game development, whenever a title encounters a problem that will impact the game negatively, the oft-heard, knee-jerk response/solution is "can we outsource?" Outsourcing resources, whether it is personnel or assets, can provide a relatively painless answer that keeps your title on track.

Almost every developer these days employs outsourcers to one degree or another. But outsourcing is not a silver bullet solution in every instance. There are many factors to consider when examining the outsourcers for your project, and whether bringing in external contractors to augment your team is the best way to bring a successful result to your game. This article will discuss best practices for bringing in an outside group to aid the development during full production.

Before getting started, it is extremely important to get off on the right foot and make the sure the development team has total buy-in with regard to the need for the outsource team's involvement.

Some teams welcome outsourcing, some outright will say no, and some will say yes and then proceed to passive-aggressively foot-drag and sabotage all work being done by the outsourcing team.

Often, it is the publisher that will first suggest employing outsourcers, and many developers regard advice from publishers on development matters with an eye-roll.

Therefore it is incumbent on both sides of the publisher/developer table to come to an agreement that employing an outsource group is the best solution to the issue at hand, and then communicate this up and down the chain within the respective organizations.

In this case, you have to lead the horse to water AND make it drink -- if it is the best, most efficient way to solve a problem.

Due Diligence

Performing adequate due diligence is an obvious, yet frequently ignored, critical first step. In the rush to provide a solution, developers will grab any available group with bodies and availability and throw them at the problem.

While this may make the people upstairs happy because you are "doing something", it is fraught with danger. A more thorough process that allows you to kick the tires of your potential outsourcers will save you time and headaches in the long run, guaranteed.

Your first round of due diligence should involve looking at the portfolio of work as well as the state and composition of the outsource studio. This includes:

  • Past titles they've worked on. Do these types of games closely match your game?
  • Types of work they've done on these titles. Almost every outsource shop nowadays has a specialization, so merely getting an "art" outsource may not meet your particular needs. Don't get level artists if you need concept work.
  • Quality of the work, and time it will take the outsource group to create it. Create a sample spec document that is representative of the work you need performed. Monitor how long it takes for them to finish the sample and the quality of work. This should provide a ballpark baseline of the quality/tempo of their output.
  • The financial state of the outsource organization. Are they agreeing to all terms and conditions because they are on monetary life-support, or because they are just acquiesce to everything because they are so darn accommodating? The last thing you need is to discover the outsourcer closed its doors midway through their task, leaving you high and dry, and in a worse predicament than before.
  • The personnel the outsourcer will task to work on your project. It may be great if the company provided stellar assets for a AAA title that sold 5 million units, but if you're getting a different team within the company which had nothing to do with said smash hit, it doesn't help your needs. Make sure any contract you have with this team (see below) identifies by name key personnel who will be involved for the duration of the project.
  • Related to the personnel point, above, be aware that many outsource groups utilize subcontractors as well.
  • Reputation and word of mouth. Have you worked with this group before or know anyone else who has? Odds are, in this small industry, you can ascertain whether or nor not this outsource group will mesh well with your team, just from experiences you or others have had with them.
  • Make sure you sit down with the development team and ascertain what exactly they need. Poll the leads and let them tell you what will work best for them, and make sure they have had the opportunity to vet and approve the outsourcers. Make sure the developer owns the decision to use a particular team. A shotgun marriage just won't work.
  • Once you have a decent grasp of all of these points, create an outsource plan that delineates all of the above. Identify all of the pertinent stakeholders, ascertain their needs and areas of interest, and what they require for these needs to be met.

    This includes not just the developer and production team, but also those persons who will also be involved, such as Legal and Finance. Clearly show the total cost, payment terms, work product, and schedule for completion. Set concrete time limits for submission of assets, feedback on the assets from the dev team, the named person responsible for supplying feedback and approval, and approval times.

    As an example, one developer required that the art lead provide all feedback on assets. Unfortunately, there were no limits on how long the art lead had to provide feedback, and as a result it required constant prodding by several people to get the necessary feedback from the lead. In turn, this wasted precious time on basic housekeeping task that should have been a no-brainer.
  • The most important item to remember harks back to 1975, when Frederick Brooks wrote The Mythical Man-Month. In essence, the book shows that adding people to complete a task does not always realize efficiencies of time, as tasks often have to happen in sequence, not in parallel.

    The frequently used example to demonstrate this theory is that if it takes one woman nine months to have a baby, then it should take nine women one month to have the same baby. Clearly, this is absurd. In practical terms, it just means that adding more people to complete a task, if the production pipeline calls for one person, usually a discipline lead, as the gatekeeper to moving the process forward, will fail. The lead becomes overwhelmed, no matter how many people are aiding in the work output.

Article Start Page 1 of 3 Next

Related Jobs

JDRF — San Francisco, California, United States

JDRF Game2Give Community Manager
Disbelief — Cambridge, Massachusetts, United States

Disbelief — Chicago, Illinois, United States

Senior Producer
Stern Pinball, Inc.
Stern Pinball, Inc. — Elk Grove Village, Illinois, United States

Senior Embedded Software Engineer / Senior Systems Software Engineer

Loading Comments

loader image