Selecting Team Members from within the Organization Selecting team members from within your organization follows roughly the same process as hiring someone from outside the company, but tends to be much less formal because you already know something about the people being suggested for the team. You might actually have less say in which existing employees are on your team than you would if you hired someone because other factors, such as availability, priorities, relationship with the functional manager, and so on, contribute to the decision. Establishing Team Structure and Roles One of the advantages of virtual teams is that team members tend to focus more on getting the job done than on the office politics and gossip that often derails colocated teams. To facilitate this focus, managers and team leaders must be explicit about expectations, structure, and roles.

Expectations As a team leader or manager, your expectations, assumptions, and responses to questions and situations set the tone for the project. In addition, team members come to the project with expectations, assumptions, and needs of their own. When establishing the team, it is important to identify such expectations and to ensure that, by the end of the initial meeting (see the section in this article titled “Initial Meeting”), the team is focused on the same objectives and has the same expectations about the project. Think about and document the following areas when defining your expectations:

-  Communication between team members, with upper management, with functional groups, with customers, and with other employees -  Vision for the project -  Behavioral expectations (e.g., time, how well people play in the sandbox with each other, conflict management, and so on) -  Escalation pathways for conflicts and disagreements that cannot be resolved within the team

-  Recognition and reward

-  Percentage of available work time that each person will devote to the project -  Relationship of project to other priorities

-  Hierarchy

-  Percentage of time for billable work and for administrative work (it is unrealistic to expect much more than 80 percent billable hours, particularly if the job requires intense concentration or creativity)

-  Methodology for measuring success. Some expectations may require negotiation with the team, so be prepared to discuss areas of disagreement or misunderstanding during the initial meeting. Be conscious of conflicts that arise as the project progresses due to unspoken or unconscious expectations. As they arise, document team decisions, and ensure that the entire team is aware of the expectation. Structure, Roles, and Responsibilities The structure of the team and its relationship to the corporate hierarchy forms the framework upon which the roles and responsibilities hang.

The structure of the team defines how each functional area will work together, as well as who shows up for reviews, who manages changes, who works with whom, and how often meetings are held. Each member of the team should have a clearly defined and documented role and set of responsibilities for the project. These responsibilities might have significant overlap with the person’s overall job description.

Then again, they might be highly specific to the particular project. For example, one medical company had a major product recall due to a malfunction that was causing serious injury and death. The company pulled its top performers onto the recall team to address the problem. Team members found themselves performing duties that, while outside their typical responsibilities, were necessary to save lives and to find out how to fix the problem. Be careful of the “other duties as assigned” statements; such phrases tend to be a catch-all and, if you are not careful, can often distract the team from its primary task due to conflicting priorities from project management and line management. For areas of overlap, be sure to define decision trees to help determine who deals with the issue. The more clear you can be, the fewer conflicts you will have within the team and the more easily team members can direct someone to the appropriate person. Leadership On virtual teams, leadership is shared. While one person might be assigned as the project manager, responsible for the budget and schedule, everyone on the team provides leadership in some area. For example, team members who are experienced with working virtually typically take extra time at the beginning of the project to find ways of establishing rapport with their distant colleagues, and are very proactive about their communication.

Other team members are good at planning teambuilding activities, and connecting people comes naturally to them. Still others are highly competent technically and become the “go-to” person on some aspect of the project. A good team leader actively encourages these unofficial roles because the team becomes more invested in the project if each member feels that his or her contribution matters. As mentioned in Article 1, the leader’s attitude, particularly at the beginning of a project, sets the tone for the entire team. It is important, therefore, that the leader resolve any conflict or doubt about the goals of the project before setting up the team. Core Team The core team on a project typically includes the functional leads from each discipline required to complete the project. These team members get involved at the very beginning of the project and stay involved throughout the process.

These core team members typically include the following roles and areas of expertise:

-  Project manager

-  Requirements analyst

-  Design engineer/developer

-  Documentation

-  Localization manager

-  Marketing

-  Regulatory affairs (medical or other regulated products)

-  Testing/quality assurance

-  Manufacturing/packaging

Depending on the complexity of the project, these core members might have additional people working for or with them on the project. However, the team leads are the ones who provide the continuity, attend most of the project-related meetings, and review or collate their functional group’s comments before presenting them to the project team. Associated Subject Matter Experts In addition to the core team members who stay with the project for its duration, subject matter experts (SMEs) might be brought in to assist with specific aspects of the project.

These SMEs typically have specialized skills or knowledge that the project team needs to access for a short period of time. Examples include reviewing the final engineering diagrams for electrical issues, providing assistance with troubleshooting a particularly complex testing issue, evaluating the ethical issues that arise during a clinical trial, and so on. These experts typically work with the core team members on a specific task and then move on to other work. The core team members are responsible for ensuring that the SMEs have the information that they need to accomplish the tasks assigned to them. Localization and Other Vendors Companies often hire contractors or consultants to assist with aspects of a project that are outside the company’s primary focus. Localization is a primary example. Bringing localization into the project early can reduce costs and problems later on. Particularly for large projects that involve many languages, it is a good idea to include the localization vendor in the initial project meeting and to keep the vendor apprised of project status throughout the project. Many companies assign a localization manager to act as a liaison between the localization vendor and the project team. This localization manager identifies issues that may affect the schedule or localizability of the product. Some companies also have a vendor manager who works with subcontractors on a project to ensure that they have everything they need. This arrangement is particularly helpful if the vendor in question is developing a component that must later be integrated into the product as a whole. (See Article 6 for more information on working with vendors.) Setting the Ground Rules Once you have established the team structure and have identified the core team, it is time to get the project started. The tone and organization of the start phase has lasting implications on how well the entire project goes, so it is imperative that you carefully plan the initial meeting, teambuilding activities, and guidelines for team interaction. In addition, if you have members of your team who are not experienced in working virtually or in multicultural environments, consider assigning them a mentor who can work with them and guide them as they learn their role.

Initial Meeting The initial meeting sets the tone for the project, so during this meeting it is vital to accurately set expectations and ensure that everyone understands the goals, deliverables, and schedule for the project. Perhaps even more important, however, is the rapport building and teambuilding that occurs. It is best if this meeting can take place in person. The cost of getting everyone together for a few days at the beginning of a big project will be saved many times over with fewer conflicts and better communication. Shared experiences and goals are the fastest ways to build rapport within a team. If you absolutely cannot hold the initial meeting in person, try to hold a video conference. From a psychological and sociological standpoint, it is important for people to be able to visualize their teammates so that they can “hear” and “see” the human being on the other side of the email, instant message (IM), or telephone.

There is a tendency for people to be more blunt, to say things in email that they would never say to someone’s face, and for issues to escalate more quickly when most of the interaction is via email or IM if the people involved have never met in person or via telephone. Nothing derails a project faster than flame wars or, conversely, team members feeling that their ideas and information are going into a “black hole,” where the recipient never responds to anything he or she receives.

Communicating with the Team All the tools in the world are not going to be useful if your team does not understand how to use them to communicate effectively. Before beginning any project, it is critical to establish a set of guidelines for team communications including what information to share, which method of communication to use for each, and specifically how you expect to communicate and how often. Then you can determine which tools are appropriate for the various types of interaction your team is likely to use. Early in the process, establish and distribute guidelines for interteam communications. Enforcing clear, consistent guidelines can help prevent misunderstandings and improve the way information gets shared. Synchronous vs. Asynchronous Interaction The primary consideration when choosing a method for communicating between team members is the urgency of the message. If something is extremely urgent (think “fire alarm”), then you need to use a “synchronous” mechanism to ensure that the team members get exactly the same information at exactly the same time. Synchronous tools include conference calls, meeting software, chat rooms, VoIP, and instant messaging software.

Messages with less urgency can be sent with an “asynchronous” tool that team members can access at their convenience. Asynchronous tools let your team members access the content of messages repeatedly, and are good for reference information such as project plans, schedules, or to-do lists. Asynchronous tools include email, message boards, wikis, intranets, and blogs. One-to-One Conversations The bulk of your daily interteam communication is likely to be one-to-one. When all team members are colocated, a lot of communication occurs as casual conversations or one-to-one in-person meetings. In a virtual team, however, the one-to-one communication requires a bit more planning. If all of your team members are online most of the time, instant messaging software (like AIM, Yahoo! Messenger, or Lotus SameTime) can be a quick and easy way for team members to communicate with each other. Messaging tools generally allow team members to set up the software to display whether or not other team members are online and available, and can be set to store a log of each conversation (though many people do not use the logging feature).

VoIP and chat rooms can also be used for one-to-one meetings, depending on the relative cost and ease of access to the team members, though VoIP technologies might be more complex to set up and possibly more costly than is efficient for brief discussions. One-to-Many Email Most of us are fairly comfortable with email communication. It is easy to fire off a short message, and the message can be sent to numerous recipients at the same time. However, sometimes the ease of sending quick notes to many people can be one of the drawbacks of email. If you are not careful, responses intended for a specific person may get sent to the wrong recipients. Many senders have regretted messages sent in anger or been embarrassed by writing a private message (usually something critical or uncomplimentary) and then sending it “to all.” As with any written communication, the sender can sometimes “hear” one message while typing, but the person on the other end gets an entirely different message. Humor does not often come across very well, and the nuances of language, like sarcasm, metaphors, or informal expressions, can be easily taken the wrong way. Misunderstandings can easily occur, particularly if your team members come from different cultural backgrounds, whether or not they are using the same language.

Many of the drawbacks of email can be avoided or minimized by establishing and distributing a set of guidelines for email communication within your team. The guidelines are likely to vary by team and project. For example, if some team members use email software that cannot handle large attachments, you might want to specify alternative methods for file transfers (such as posting to a wiki or using an intranet). If some people have limited or shared storage capacity, consider establishing guidelines for how long (or where) messages are stored. Establish a subject heading convention that works for your team. For example, you might want to preface each subject line with [project name] for easier sorting, or use more specific tags like [budget], [schedule], or [status] when sending budget, schedule, or status types of email. Or you might decide on a code for very short messages that fit in the subject line so recipients do not need to open the email message at all. For example, [EOM] at the end of the subject line indicates that the entire message is contained in the subject line — there is no content in the body of the email itself. If email is a primary communication mechanism, establish a policy for how often team members will read their email — once a day, twice a day, once an hour, etc. Similarly, you might want to provide a recommended turnaround time.

For example, depending on the specific needs of your group, you might suggest that emails be answered within one working day. Many of the drawbacks of email can be avoided or minimized by establishing and distributing a set of guidelines for email communication within your team. The guidelines are likely to vary by team and project. For example, if some team members use email software that cannot handle large attachments, you might want to specify alternative methods for file transfers (such as posting to a wiki or using an intranet). If some people have limited or shared storage capacity, consider establishing guidelines for how long (or where) messages are stored. Establish a subject heading convention that works for your team. For example, you might want to preface each subject line with [project name] for easier sorting, or use more specific tags like [budget], [schedule], or [status] when sending budget, schedule, or status types of email. Or you might decide on a code for very short messages that fit in the subject line so recipients do not need to open the email message at all. For example, [EOM] at the end of the subject line indicates that the entire message is contained in the subject line — there is no content in the body of the email itself. If email is a primary communication mechanism, establish a policy for how often team members will read their email — once a day, twice a day, once an hour, etc. Similarly, you might want to provide a recommended turnaround time. For example, depending on the specific needs of your group, you might suggest that emails be answered within one working day.