I've been a "consultant" (a member of a staff augmentation force called in to help , and worked with them as well.
First off, there will be some ruffled feathers whenever the layout of a "team" changes. There are four stages of team development;
- "Forming" - team first gets to know each other by name, lays down basic ground rules for working together, starts getting into the environment. Generally takes about a week.
- "Storming" - team butts heads on differences of opinion, personalities, ego, etc. This will start to happen almost immediately and will overlap with the "norming" phase as personal conflicts arise and are resolved or overcome.
- "Norming" - team works through these differences. Management may identify HR problems in the team and take appropriate action, but most of this is simply people getting used to working with each other. This can take weeks or even months, but generally, attempting to interfere with the process too much will actually hinder "norming".
- "Performing" - the "steady state", with the team largely knowing how to work together instead of as a collection of individuals. Here, you start to see the "synergy" buzzword, where the team performs better than the sum of its parts because they interact without any retaliation or personal ambition other than to help the team. Only incremental changes should be made to the makeup of such a team, to replace attrition or augment the team; large increases, decreases or merging of teams will upset the chemistry and the process starts over.
You have to go through all four stages to get a team clicking along producing at full capacity. Trying to push through the "storming" and "norming" phases just produces a team nursing grudges, egos and general resentment of other members; it WILL blow up in the team's face eventually, and in the meantime the team, not trusting each other, will not be performing as well as they could.
Now, that being said, the formation of one team consisting of consultants and in-house developers is particularly combative. It still follows the same phases above, but the two teams merging into one come from different corporate cultures and report to different people who have little to no say in ther behavior of other people. The in-house team will likely take the stereotypical view that the consultants are coming in with 6-figure salaries to completely undo all their hard work, in the process undermining their professional standing and reputations in the eyes of their managers. In reality, the "consultants" may be on contract, getting no benefits, little job security and being told to do a job that looks insurmountable at first.
In this case, IMO it's generally better to keep the two teams as separate as possible. Two teams can work on one project, with the proper management. Consultation between teams should happen at the senior or project manager level, depending on how much the project managers are kept in the loop of specific design decisions and problems. Overlap of work each team is doing at the same time should be avoided; it's harder to hit a moving target, so Team 1 should not be depending on anything Team 2 is currently developing or refactoring and vice-versa.
This is a situation in which Agile is a very effective project management methodology. Split the work up into manageable chunks, assign independent chunks to each team and let each team figure out how best to meet the requirements. Make sure design rules are followed; when Team 2 comes across a dependency on Team 1's code, it will ruffle feathers on both sides if too much refactoring is needed.
