Working Together at a Distance

Originally Published MDDI January 2002

DEVELOPMENT TEAMS

Working Together at a Distance

Dispersed product development teams may have limitations, but there are ways to maximize their advantages.

William Leventon

Product development is challenging enough when designers are separated by walls and partitions. But it's even more difficult when they are separated by miles.

Nevertheless, use of geographically dispersed development teams is becom-ing 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 development teams.

New capabilities offered by use of the Internet have also given a boost to dispersed teams, prompting companies to change the way they deal with what Lipnack calls a "diaspora of skills." She notes that with "highly trained people in all kinds of locations, businesses started
to realize that instead of shipping the people around, they could ship their intelligence around."

Development teams can be dispersed around the country or around 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—some experts suggest that 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 is usually easier 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 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 to get together with them. "Nothing works better than getting everybody in one room at some point," says Peter Farrell, president of ResMed Inc. (Poway, CA), which 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 have never met.

Dispersed development-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

Because they will be working separately most of the time, the team members should develop a specific plan for connecting with each other, according to Lipnack. Such a communication plan might call for daily checks of the project Web site, one-on-one telephone calls every other day, and a teleconference with all team members 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."

A similar strategy can be applied to telephone calls. A telephone 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 that could be contradictory or redundant.

Communication protocols could also address language issues. For example, dispersed teams could ban the use of "ASAP." Though often inserted into written messages to suggest urgency, 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. She recommends spoken communication among distant partners, either on the phone or in a videoconference. She believes that videoconferences are particularly effective tools for improving understanding because they enable participants to observe one another, as well as to talk and listen.

Today's videoconferencing equipment produces sharper, clearer images with fewer hassles than older systems, according to Farrell, whose dispersed development teams find teleconferencing 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 the details of 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 GROWN-UP

When dispersed groups of people are attempting to work together, even the best technology won't eliminate misunderstandings from the process. When such problems occur, their impact can be minimized by handling them in a mature manner. Unfortunately, says Lipnack, 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. Instead of considering the possibility of a mistake, however, East gets annoyed at West for standing him or her up. In cases like this, Lipnack says, "we tend to jump to conclusions. That's where maturity comes in. Be a grown-up 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 explains. "Once people trust each other, work gets done more quickly."

To build trust, Kwo recommends that dispersed development 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 other 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. (San Francisco), a contract design firm. "They should share successes and progress, but they should also tell others about any [project] 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 structure the project in a manner suited to a dispersed product development team. According to Mortimore, the structure should "modularize" the various aspects of product development as much as possible. When the various parts of the product technology are not sufficiently modular, dispersed team members will have to be in constant communication in order to carry on with their work.

On the other hand, when the project is divided up properly "people can work at a distance pretty much independently of each other," he says. Occasional communication will then suffice to keep things moving along.

When devising the structure for a product development project, managers should pay particular attention to the 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 beyond the line. But nobody was handling the interface."

The lesson: someone must be responsible for maintaining an interface between project areas. For best results, Kwo believes that the designated person should have some knowledge about the other group's field. For example, an engineer handling an interface between the mechanical engineering and industrial design parts of the team should know something about the designers' work.

Even with the right structure, dispersed development teams can become disconnected over time. To prevent this from happening, Blanck advises teams to establish a series of project milestones and then celebrate when each is reached. As a milestone is achieved, "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 each 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 members of the group.

Bridge Design maintains separate Web sites for all of the company's projects. The no-frills sites include links that provide 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. For example, various user interfaces can be tried using simple software models. "Then, people can let us know how they feel about each one, whether it meets their needs, and what problems they see with it," Evans says.

Like Bridge Design, Plexus creates Web sites for each of its many projects. Team members visiting these sites can find information that is relevant to the project, such as

Dispersed development 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 explains. "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 25 to 50 dispersed teams working on different projects. "We need to have a design history file" for customers, he emphasizes. "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. For example, Resinate OEM, produced by Resinate Corp. (Andover, MA), provides a database intended to help designers choose the best plastic materials for medical devices, with less input from distant colleagues.

Resinate is intended to fill knowledge or skill gaps in the design chain, according to 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 technology realm, software combined with computers and other high-tech gear may soon let a designer manipulate a virtual model while others in different geographic locations look on. In California, a small company is refining a virtual-reality system originally developed by the U.S. Army. The system enables designers at various locations to gather in a virtual room. In this room, "when you manipulate a virtual model, everyone sees it moving," explains Paul Mlyniec, president of Digital Artforms Inc. (Los Gatos, CA). At the same time, the designers can discuss the model on the telephone.

Mlyniec is working on several versions of this system, called SmartScene. SmartScene makes virtual models from data generated by CAD programs. The most elaborate version 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 with trackers that monitor the gloves' position and enable wearers to 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 unpinch, the object is frozen in space again."

Later versions of SmartScene use such accessories as 3-D glasses, head-mounted displays, and large curved screens. Although collaborative versions of the product are still unavailable, Mlyniec expects them to be ready in the near future.

Systems such as SmartScene offer great promise; however, 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 people at the other end might not be savvy enough to use it. Or they might not have everything needed to use it. They 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."

This does not mean that dispersed teams should avoid high-tech tools, says Evans. "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," he says.

CONCLUSION

As companies spread out geographically, so do their product development teams. Dispersed teams can be problematic, but the problems shrink when teams adopt strategies that improve communications, build trust, and establish an appropriate project structure. Teams can also use the Web and various software-based tools to improve collaborative work. Because high-tech tools can cause as many problems as they solve, however, dispersed teams should proceed with caution when adopting advanced technology.

William Leventon is a New Jersey–based freelance writer who frequently covers the medical device and diagnostic industry.

Illustration by Hannah Gal/Getty Images.

Copyright ©2002 Medical Device & Diagnostic Industry