If you've worked remotely with an external group, you've probably experienced firsthand how painful that can be. If communication with people sitting right beside you can be difficult, imagine if he/she is 5k miles away

On top of that, this is not only common nowadays but you can also expect to be even more usual in the future. After all, making an AAA for the current generation often requires teams of 300 people at its peak, and few companies can maintain such amount of devs for a long period of time. Outsourcing is here to stay, either external (work for hire companies) or internal (other development groups within the same company)

In any case, prepare for the worst. Yeah, you could be lucky and everything will go smooth like silk but guess what? It won't. Any issue is magnified by the distance, and minor communication breaks become upper management fodder. In summary, there will be chaos at some point, you won't be able to avoid that. But you can certainly mitigate it to tolerable levels if you know the minefields ahead, and plan as much as possible for things not going out of hand

Here you will find a list of recommended protocols to follow on your relationships with external teams working for your project. It's solely based on my experience so I wouldn't be surprised if you have more items to add, but if you follow them your life will be much easier, I guarantee. For a better understanding, I'll use the term 'main' for the group which develops the core of the game, and 'support' for the group helping out. And without further ado, here are my recommendations:

Before the relationship begins you better...

Clear the vision - The main group needs to ensure the high level vision of the project is clearly defined, and offers little or no space for interpretation. I cannot stress how important this is, otherwise different approaches and communication failures can easily make you lose weeks of work

Decide who makes the final calls - Should be self-explanatory in most cases, but since some hard decisions will surely have to be made at some point, someone needs to have the final saying and the rest deal with it

Empower them - On the other hand, you can't be asking for validation for every little tweak you make. Once the vision has been established, the supporting group should be allowed to make their own decisions on the everyday work, as long as they fit into the vision. A sense of ownership generally boosts involvement and productivity

Give away self-contained areas - It's often a good idea to externalize chunks of work that doesn't require constant interactions with other game systems or distant departments. Game modes, whole levels or sections of the maps are good examples of relatively isolated sections of work that can be sent away. The support group will move faster and make better decisions if that's the case

When you first discuss the relationship, it's good to...

Define the contact persons - Avoid at all costs a situation in which multiple people are the ultimate responsible for everyday communications. Define at least one that is supposed to chase up people if the others don't answer mails

Share team info - It's a good practice to exchange the names and titles of the teams, so whenever a mail is received people don't waste time finding out who's that guy and why he cares about a certain issue

Establish the communication tools - Practically each person prefers a different one. You don't want to find out mid-way that X can only be reached through skype while Y favors phone calls. Define which tools you'll be using and how

Define build protocols - One of the most common frustration choke points, in my experience. Clear up as much as possible which build branch each will be working on and submission protocols. Seriously, it's amazing how much time you can lose on discussions regarding this topic

Create a friendly relationship - If you manage to build up a good working relationship between the main and support groups, you will cushion many miscommunication issues. Not always easy, but you can start selecting people less prone to be problematic for these key contact positions

And while you're on it, you should...

Have a first visit - Once the collaboration has been settled, if possible try to move a group of representatives from the support group into the main studio. Let the devs sync and build up healthy relationships

Have more visits! - As much as the budget and the production schedule permits, try to have both teams sitting together regularly. Again, communication issues will be less common, and although the main studio may have to divert some valuable time into it, the support group will move much much faster

Establish a clear visit agenda - Expect everybody in the main group to be very busy, every minute is precious. Plan ahead an agenda and make daily adjustments if needed

Be aware of the time differences - It's highly probable that both groups are in different time shifts. If that's the case define which is the best hour for each team to be online simultaneously and try to force the bulk of the communication around that time. This could force contact people to adjust their daily schedules to be available at those hours

Give visibility to your work - Last, but not least at all. Actually this is a critical point which can cause many conflicts if it's disregarded. Keep other dev groups aware of what you're doing. It's often not only highly relevant for their work, but also makes confusion disappear from upper management, which saves you time on the phone or doing political work in the worst cases. A weekly status report, newsletter or Wiki page is highly advisable

Good luck, and may the patience be with you!