Outsourcing: A Little Checklist to Save You a Lot of Hassles
June 22, 2010 Page 1 of 3
[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.
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.
Page 1 of 3