Requirements Team Building

How do you build a team that is spread throughout various locations? First we have to define the word team. There are several definitions of the word team. This is the one that most closely applies to the requirements world. "a number of persons associated in some joint action": a team of advisers. This definition suggests that geography is not important to the team concept. However, experience suggests that a team that is segmented in different locations will have less cohesiveness and create communication challenges among other things. How do we gather, define and disseminate requirements on a project that will be developed overseas for instance. Well, the common ways in which to handle this issue is to use email, conference calls and travel.
Let us assume that there are no language barriers, only distance barriers in this scenario. How do we effectively deliver requirements and coordinate with the developers who are not local? Teams thrive on having a common theme. This could be a common color, fight song or method of operation. We could use face paints and mascots, but that may not always be practical in a business environment. We could create a song for each project that all of the members have to sing together at the start of each meeting, but not everyone will want to participate. Uniforms are often a good way to create the feeling of a team.
I would say that the method of creating the "team look and feel" can change based on the project and the team members. It should be something that the majority of the members agree is fun. This can be decided during the kickoff meeting.
The point is not simply to bond, but to create a sense of responsibility to the group and the overall success of the project. Product Managers and Analysts are often individuals and introverts. Creating a cohesive team will help to tame the alpha personalities and include the omega personalities that exists in every group. We want to create an "Army of One", to use military marketing campaign phrase.
Try to use this concept on a new project and compare the results with a similar project that did not tackle this issue from the beginning. I’m guessing that there will be mixed results, but that is still better than the status quo.