A little knowledge...

Let's start with knowledge. Knowledge on a project can cover a lot of ground, from basic procedures (how to build the programs) to the corporate history and mission and how it affects the design of programs. Some knowledge can be encoded in written procedures, step-by-step lists of operations that provide a specific result. Other knowledge is subtle, and requires good judgement.

This second type of knowledge is hard to acquire and is something that cannot be easily transferred to another person. It is learned only through experience, through trial-and-error, through guidance and mentoring. Knowledge of the first time, in contrast, can be transferred by simply handling a document to a person.

This division of knowledge is not limited to development projects or even IT. Groups such as the Boy Scouts cope with these two types of knowledge. The scout manual covers the basics, but the "good judgement" skills require experience and leadership from other scouts and scoutmasters.

So here is my "great insight":

With a team that has high turnover, the only knowledge that one can expect is the knowledge of the first type, the easily documented procedures. Members of a high-turnover team do not invest enough time in the project to learn the "judgement stuff". Therefore, members of a high-turnover team cannot be expected to "use good judgement" to make decisions and resolve issues; they can only use the documented procedures.

This has ramifications in two areas. One is the documented procedures, the other is the tasks that can be assigned. Documented procedures must be clear and simple, and based on a base of expected experience. They must be of a limited size, something that can be read in a reasonable time. They cannot be a large tome of all possible conditions and desired outcomes -- people will not be able to absorb all of it or navigate to the proper section.

Tasks assigned to a high-turnover team are limited. One cannot assign tasks that require judgement based on knowledge of the corporate culture and project history -- team members will never have this knowledge. (If the outsourcing provider claims that the team can handle such tasks, then the provider must show that the team will have this long-learned knowledge. But I suspect providers will limit their claims to procedure-driven tasks such as coding and execution of test scripts.)

Knowing these limits on outsourcing guides the client company's strategy. With a high-turnover team, the client company must prepare clear and comprehensive procedures for specific tasks. The client can assign procedure-driven tasks but not judgement-driven tasks.

If the client wants to outsource judgement-driven tasks (project management, UI design, test script composition) then the outsourcing company must provide long-term, low-turnover teams. If they cannot, then the client cannot assign those tasks. (At least, not if they want to be successful.)