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.

Where will the actual outsource work be performed? Onsite is optimal, but rare, and often expensive even if it possible. Be aware that even if you are lucky enough to secure outsource workers on-site, unless the development team is on-board with the new group, problems can and will arise.

Several times I've worked on projects in which we've moved heaven and earth to get them working at the developer, usually at great cost and inconvenience to all involved, only to later find the dev team largely ignoring them.

Sometimes it's overt, like when the outsource team was forced to work in an unheated conference room in winter. Other times it's more subtle, like the dev team that kept "forgetting" on a daily basis to inform the outsourcers that dinner had arrived during a crunch when all hands were on deck 16+ hours day at the dev studio.

If the team cannot work onsite, see if you can arrange to have the outsourcers on-site for a week or two. This will enable the outsourcers have a "boot camp", if you will, into the processes, pipelines, and personnel that the studio utilizes. At the very least, once everyone has had a chance to put names with faces, it helps communications by orders of magnitude to not see people in either group as just an email address or voice on a conference call.

If offsite, what is the time zone difference? The farther apart developer and outsourcer are, the more difficult real-time communications become. On the flip side however, if the developer is literally half a world away, the resultant lag can be beneficial, as it provides a 12-hour buffer in which to review the assets; it provides a chance to review the deliverables with more breathing room.

How will the two groups talk with each other? Does the developer have a point person to coordinate and disseminate the assets internally, as well as supply relevant information and feedback to the developer (best case), or will assets delivered to the already over-worked lead(s) (worst case)?

One project I worked with had an inordinate number of outsourcers required, including on-site, individual contractors as well as over 10 different outsource groups, across all disciplines, working offsite. In the end, it required one dedicated person at the developer, plus several additional people on the publishing side to coordinate and arrange all of the paperwork to process.

It was a herculean task, and one that could have been mitigated with better planning on both sides, as well as a clear understanding from both parties on approval process to greenlight the overall outsource plan.

Furthermore, with so many outsource groups located in India, Russia, and China these days, determine that there is a sufficient quantity of speakers of the desired language (generally English) so that queries and information can be exchanged at a peer-to-peer level for mundane daily issues. Of course, this assumes both groups are comfortable with non-critical conversations occurring outside of the main communication chain.

Aside from assets and documentation between teams, there needs to be regular conversations via conference call, IM, and if possible, video conferencing. It might seem like a hassle to have the whole team assembled for an hour to answer some questions from the outsourcer, but 30 minutes on the phone is better than exchanging and forwarding a day's worth of emails explaining the same issues. Make this meeting mandatory for all concerned.

Once the developer and outsourcer have gotten familiar with working with each other, and one cycle of asset delivery has occurred, it is a good idea to sit down with both sides and figure out what worked, and what did not. Identifying and correcting problems or hiccups now is much better than waiting until the project is over to do a post-mortem.

One developer had a fairly good system of tracking each asset in its various stages of completion, which was shared with the outsource team. However, the outsourcers regarded the early stages of work as being more a guidance than a requirement, so when they submitted assets which the outsource team considered to be fairly far along, the assets were rejected because the outsourcers had strayed off-target on the deliverable, as they made some key assumptions that were not in line with what the developer expected.

The original intent of the tracking document was to allow the developer to course correct the outsourcers' work product course in more discrete chunks along the way, and theoretically prevent deliverable expectations to snowball wildly off target. A mid-sprint post-mortem revealed that the developer did not really emphasize the importance of the tracking document, and that the outsourcer failed to see its relevance or importance, and just regarded it as one more piece of paper.

Don't let the tail wag the dog. Time and again, developers get exasperated with an outsourcer because they begin to think, after answering a blizzard of questions, that it would be quicker and easier if they just did the work themselves. It's a common trap, and oftentimes seems quicker, but it's really only a short-term solution.

Granted, outsourcers may often require a fair amount on bandwidth from the dev team during ramp-up, but if you've done your homework, and have the right team and processes in place, chances are that in two weeks time you'll find that percentage of time you spent hand-holding outsourcers is greatly reduced.

Most contractual considerations are taken care of by the lawyers, but it is important to be aware of these items.

For example, make sure Non-Disclosure Agreements are in-place; define who has the final say in whether an asset delivered meets the requirements of the work; what happens when one side fails to meet their obligations; what are the terms of payment, and so on.

The work specification, generally provided by the developer, is the blueprint, recipe, and wish-list for the assets to be provided. The depth and clarity of the Spec are the primary resources for the outsourcer; write a quick and sloppy Spec, and you'll almost certainly get the same result back.

Descriptions, annotations, and examples will be a boon for the person on the other end implementing your Spec. Don't assume the outsourcer "knows" a certain model has a polygon budget of X, because it's to be implemented in Area Y. Quantify whenever possible.

Documentation, in this case, primarily falls into the arena of asset tracking. Spec delivered? Check. First Pass asset delivered? Check. First Pass Feedback delivered to Outsourcer? Check. And so on. This document should be organic, and shared by developer and outsourcer, in order to provide total transparency. Any red flags are then obvious to both parties.

Developers live and die by milestones, so it is important to set up a milestone delivery schedule that works well for both parties. The developer almost certainly is already working off of a pre-existing milestone schedule, so integrating the outsourcing into that schedule, and by extension, the development pipeline, is paramount.

A code/asset drop from an outsourcer two days before a developer milestone is due just won't work. Provide ample, and realistic, time to integrate assets into the game, especially for the first for the first few deliverables from the outsourcer.