Working Together at a Distance Dispersed development teams don’t measure up to teams in one place, but there are ways to minimize the disadvantages. William Leventon Product development is tough enough when the designers are separated by walls and partitions. But it’s especially difficult when they’re separated by miles. Nevertheless, geographically dispersed development teams are becoming more common, according to Jessica Lipnack, a management consultant in West Newton, MA. “Companies have decided to tap resources that aren’t under their noses,” says Lipnack, who focuses on issues related to dispersed teams. The rise of the Internet has also given a boost to dispersed teams, prompting companies to change the way they deal with what Lipnack calls the “diaspora of skills.” “With highly trained people in all kinds of locations, businesses started to realize that instead of shipping them around, they could ship their intelligence around,” she notes. Dispersed teams can be spread around the country or the world, encompassing people with different languages, cultures, and philosophies. Though this can be helpful — for example, team members in different countries can provide culture-specific design input that will boost sales of products marketed where they live — experts say the advantages of dispersal are greatly outweighed by the disadvantages. “There’s no way to replace face-to-face [interaction],” Lipnack says. “We can only compensate for the lack of it.” Effective Communication To succeed in a joint effort, people working apart must find effective ways of communicating with each other. “You don’t want to work in a vacuum,” says Jennie Kwo, vice president of technical development at Product Genesis Inc., a contract engineering firm in Cambridge, MA. “And it’s much easier to work in a vacuum when you’re dispersed. It’s easy to forget that there’s a development partner across the country who’s working toward the same goals but has no idea what you’re doing on a day-to-day basis.” Long-distance communication usually goes better among people who have built relationships with each other. “You’re much more patient and understanding with people you know than with people you don’t know,” notes Emily Blanck, a management consultant in Moraga, CA. “When you’re dealing with a faceless person you don’t know, you make assumptions that they aren’t cooperating for all sorts of reasons that usually aren’t true. And things go downhill from there.” Perhaps the best way to build relationships with others is getting together with them. “Nothing works better than getting everybody in one room at some point,” says Peter Farrell, president of ResMed Inc., a Poway, CA-based company that uses dispersed teams to develop respiratory products. Blanck agrees, noting that her research and consulting experience show that teams that meet face-to-face are much more successful than teams that never meet. Dispersed team members should meet as early in the process as possible, says Bill Mortimore, chairman of Merge Technologies Inc. (Milwaukee). Early meetings produce a bond that improves subsequent long-distance communications, notes Mortimore, whose company employs people in Milwaukee and Toronto who collaborate on the development of radiology systems. After the initial meeting, additional gatherings may be particularly helpful at certain stages of a project. “There are points during design reviews where we want the dialogue between the technical staffs to be very pointed and thorough. And the most effective way to do it is face to face,” says Jeff Castleberry, director of operations at the Boulder, CO, facility of Plexus Corp., a contract engineering and manufacturing firm based in Neenah, WI. Spanning the Distance Most of the time, though, dispersed team members will be working apart from each other. To improve communication that spans distances, Lipnack thinks teams should develop a plan for connecting with each other. A communication plan might call for daily checks of the project Web site, one-to-one telephone calls every other day, and a teleconference once a week. According to Blanck, the plan should include ground rules for communication. “If you get an e-mail, the [rule] could be that you should respond in two hours,” she says. “That doesn’t necessarily mean you have to answer the question in that time. Maybe you’ll just say, ‘I got your e-mail. I’ll get back to you in two days.’ This keeps people from feeling ignored.” The same goes for telephone calls. A phone protocol could require team members to respond to calls within four hours. “What the protocols are doesn’t matter,” Blanck says. “What matters is that everyone on the team knows what they are and complies with them.” Another ground rule could establish one point of contact at each place where project staff are located. That way, says Kwo, a person in one location won’t be sending e-mails to five different people in another location — and getting five different responses, which could be contradictory or redundant. Protocols could also address issues of language. For example, dispersed teams could ban the use of “ASAP.” Though it’s often dropped into written messages, ASAP “doesn’t have any teeth in it,” says Preston Smith, a management consultant in Portland, OR. “It means something different to each of us.” Though e-mails and other written messages are useful tools, Kwo has found that they’re often misinterpreted. So speak to your distant partners, she advises, either on the phone or in a videoconference. She thinks videoconferences are particularly good tools for improving understanding because they let you observe the people you talk to as well as listen to them. Today’s videoconferencing equipment produces better images with fewer hassles than older systems, according to Farrell, whose dispersed teams find the technology particularly useful when examining plastic models. “It’s show and tell,” he says. “If you’ve got a model sitting in front of you, you can show everybody how something fits onto it, how a new feature looks, how to plug it in.” In Blanck’s experience, videoconferencing has been most helpful when someone was trying to explain a design flaw or manufacturing problem to a dispersed group. “In cases like this, it’s a wonderful tool,” she says. “You can take a video camera and point it at the problem [area]. And people around the world can actually see the problem, rather than just listen to someone trying to describe it.” Be a Grownup When dispersed groups of people are working together, even the best technology won’t banish misunderstandings from the process. When these crop up, the best way to minimize their impact is to handle them in a mature manner. Unfortunately, Lipnack says, many people take the opposite course, falling prey to immature impulses. Take the example of a West Coast person who makes an appointment to call an East Coast colleague at 10 a.m. on a particular day — but forgets that the two of them are in different time zones. On the appointed day, 10 a.m. comes and goes for East without a call from West. But instead of assuming there’s been some mistake, East gets annoyed at West for standing him up. In cases like this, Lipnack says, “we tend to jump to conclusions. That’s where maturity comes in. Be a grownup and give people the benefit of the doubt.” Perhaps more important, dispersed team members must trust each other. “Trust is the grease for the process,” Lipnack says. “Once people trust each other, work gets done more quickly.” To build trust, Kwo recommends that dispersed teams take advantage of occasions when members are gathered in one place. “Spend time with the people you’re working with,” she says. “Go out and do things together as a team. This fosters the sense of team ownership of a project.” For managers, the task is to create an environment in which workers trust each another enough to be open and honest. “Every team member must feel good about sharing all aspects of the design process,” says Bill Evans, president of Bridge Design Inc., a San Francisco-based contract design firm. “They should share successes and progress, but they should also tell others about any warts. They shouldn’t cover up problems.” To a large extent, the corporate culture created by management determines whether or not team members share information in a timely manner. “Some companies have a culture in which it’s acceptable to take risks and make mistakes,” Evans says. “Other companies don’t, so there’s a lot more covering up. And that will eventually come home to roost.” Project Structure Besides creating a culture of trust, management must develop a project structure suitable for a dispersed team. According to Mortimore, the structure should “modularize” the various aspects of product development as much as possible. When the different pieces of product technology aren’t sufficiently modular, dispersed team members will have to be in constant communication in order to carry on with their work. But when the project is divided up properly, he says, “people can work at a distance pretty much independently of each other.” Occasional communication will then suffice to keep things moving along. When developing a structure, managers should pay particular attention to boundaries between different parts of the project. “We’ve run into [boundary] problems a few times,” Kwo recalls. “We were responsible for things up to a certain line and our client was responsible for things up to the line. But nobody was handling the interface.” The lesson: someone must be responsible for an interface between two distant groups. For best results, Kwo believes that person should have some knowledge about the other group’s field. For example, a person handling an interface for the mechanical engineering group should know something about the other group’s industrial design work. Even with the right structure, dispersed teams can drift apart over time. To prevent this from happening, Blanck advises teams to establish milestones and then celebrate when they’re reached. At each milestone, “let everyone know what’s happening and thank them for their efforts up to that point,” she says. “This is a good way to pull people back into the project.” Help on the Web Project Web sites can also help hold dispersed teams together, says Lipnack, whose company, NetAge Inc., sells software for creating Web sites that simulate real team rooms. In this virtual team room, the purpose, goals, and results of a project are posted on the “walls.” The room also contains the most current project data, the project timeline, and contact information for people in the group. Bridge Design maintains Web sites for all the company’s projects. These no-frills sites include links that give users access to illustrations, videos, and other forms of information about a project. The Web sites can also help product design teams solicit feedback from potential users around the world. Using simple software models, for example, Bridge designers can let people try out various user interfaces. “Then people can let us know how they feel about each one, whether it meets their needs, what problems they see with it,” Evans says. Like Bridge, Plexus creates Web sites for each of its many projects. At these sites, visitors can find: · A library of all the information received from a customer. · All deliverables — schematics, specifications, requirement documents, etc. — produced during the project. · Contact information for everyone working on the project. · A photo gallery. “We can post snapshots of the product or test setups if customers want to see them virtually rather than come visit us,” Castleberry says. · An Open Issue List, or OIL. Developed by Plexus, the OIL is an automated action-item tracker. During the project, members of the development team put items into the OIL and close them as necessary. The OIL provides “a complete history of all the design conditions and issues that have been generated during the course of the project,” Castleberry says. Dispersed teams need a common repository of project information, says Mortimore, whose teams share data via a virtual private network for security purposes. “People squirreling things away on their private PCs isn’t a scalable business model,” he says. “We have a shared repository so people know the latest versions of the myriad pieces of software needed to build a particular product.” In the development of medical devices, it’s particularly important to have a common repository of project information, says Castleberry, whose company usually has between 25 and 50 dispersed teams working on different projects. “We need to have a design history file” for customers, he says. “But we want to have it compiling as we go along so that at any given time customers can audit our work.” Software Tools Other tools for dispersed teams include software packages designed to assist with product development. Produced by Resinate Corp. (Andover, MA), Resinate OEM provides a database that’s supposed to help designers choose the best materials for plastic medical devices with less input from far-flung colleagues. “Resinate effectively fills the skill or knowledge gaps in the design chain,” says Chris Poirier, Resinate’s senior vice president. “It reduces the number of people who have to contribute to the design and also reduces the contribution those people have to make.” In the gee-whiz realm, software combined with computers and other high-tech gear may soon let a designer manipulate a virtual model while others in different locations look on. In California, a small company is refining a virtual-reality system originally developed by the U.S. Army. The system allows designers in different locations to gather in a virtual “room.” In this room, “when you manipulate a virtual model, everyone else sees it moving,” explains Paul Mlyniec, president of Digital Artforms Inc. (Los Gatos, CA). At the same time, the dispersed designers can discuss the model on the telephone. Mlyniec is working on several versions of this system, called SmartScene. SmartScene produces virtual models from data generated by CAD programs. The most elaborate form of the system requires dispersed users to enter their own “caves,” rooms that surround them with screen projections of the virtual environment. But the low-level configuration requires only a workstation and special pinch gloves, which include trackers that monitor the position of the gloves and let wearers interact with virtual objects. “If I reach out and touch a virtual object, you’ll see it light up,” Mlyniec explains. “Then if I pinch thumb to forefinger, the object is in my hand and I’ll see it move around on the screen. And when I un-pinch, the object is frozen in space again.” More sophisticated versions of SmartScene require accessories such as 3D glasses, head-mounted displays, and large curved screens. Collaborative versions of the product aren’t available yet, but Mlyniec expects them to be ready later this year. Though systems like SmartScene offer great promise, Evans cautions against pushing the collaborative process to the cutting edge. “You have to keep it simple,” he says. “The more elaborate you make a presentation, the more likely it is to fail. The person at the other end might not be savvy enough to use it. Or he might not have something he needs to use it. He might be in a remote community where they don’t have a high-speed [Internet] connection. But if you use small, low-resolution images, people will be able to see them even if they don’t have a T1 line in their office.” Does this mean dispersed teams should shun high-tech tools? Not at all, Evans says: "Move with the times and use state-of-the-art technology, but use it in its simplest and most reliable form. Don't go to the bleeding edge, because that's where you get cut." This article appeared in Medical Device & Diagnostic Industry magazine.