Getting ready to collaborate

A few recent articles may give the impression that design departments just discovered the benefits of collaboration. Of course it's absurd to think that Wilbur and Orville Wright were not collaborating because they did not have the Internet. What's different now is the speed and precision possible from collaborating online with clients and colleagues around the world.

In a nutshell, collaboration software lets dispersed engineers send, view, and mark up drawings, and even share the controls of a solid modeler while they simultaneously design a product. The upshot is that tasks that took days in past workflows now shrink, in some cases, to minutes.

It turns out that implementing a collaboration system has a lot in common with the way in which a PDM system was rolled out almost a decade ago. For instance, experts suggest flow charting current business practices that might be reengineered, setting goals for what the new system will do, and finding a champion to guide the implementation.

But if that ordeal turned your hair prematurely gray, relax. There are also a lot of differences between the systems. Many tell of nearly zero learning curves. And the benefits are recognized immediately by others. Once even a pilot system starts up, potential users quickly see what it can do for them. Chopping just one three-day, out-of-the-office design review to an afternoon quickly captures staff enthusiasm and generates ideas for additional uses.

Implementing a system takes a little planning. To find out exactly what that is, we asked developers and collaborationsoftware users what advice and guidelines they might offer those just about to implement an online collaboration system.

GUIDELINES
With the ordeal of implementing a PDM or EDM system fresh in mind, some managers might think a collaborative system to be equally arduous. After all, anything that changes a company's process necessarily changes individual behavior. And people resist change. So one development in collaboration software has focused on getting implementations up and running fast. "For instance, a few out-of-the-box solutions address specific business problems," says Robin Saitz with PTC in Needham, Mass. "Instead of one-size-fits all thinking, as is common with a general-purpose collaboration software, a well-developed program comes with best practices to solve particular business issues such as design collaboration or engineer-to-order. These can be applied to industries such as automotive, aerospace, or consumer products. Fine-tuning can come later."

"If you want the biggest ROI for the buck," says Joe Malloni with SDRC, Milford, Ohio, "I'd suggest not just automating what a company already does. Instead, take a look at the collaboration functions and find new ways of doing things." Automating existing noncollaborative processes might deliver 10 to 20% productivity boost, he adds, but installing a company-wide collaborative program has the potential to boost things by 50 to 60%.

Start small but think big. "For example, start with online design reviews. It's easy and provides a quick payback. It was once done by gathering everyone in the same room around a table, and it probably involved travel for some team members. That can be done online and without travel, but with the same amount of interaction and a quick payback," says Malloni.

And long term, "Plan on getting away from pockets of collaboration," he adds. "It will make these systems more successful because it should go across the entire product life cycle."

But don't go overboard with an implementation plan. Trying to change too much too quickly can create problems, so Cliff Stockley with Framework Technologies, Burlington, Mass., suggests changing as little as possible. "Just about all enterprise software programs require changing business processes. That is time consuming and frustrating. We've found, based on independent studies, that even without changing your processes, a collaborative product-development system can reduce time to market and product-development cycle times by as much as 22%.

An initial goal could be to provide a more-effective means for releasing drawings. "As engineers start using the tools, and come to fully understand their power, they'll discover better ways to change the process," he says. "Later project-Web sites evolve to become very different from the initial ones. The system then becomes not a revolution forced on the group, but rather a natural evolution that captures and reflects the company's culture and best practices."

As with PDM systems, it's a good idea to have a champion or advocate to guide the roll out. This person can come from an engineering group or from upper management. "Anything that requires process changes needs a champion," says SDRC's Malloni. "That's been true for 30 years. Developers can change technology, but they can't change people."

"Candidates for the champion could be the head of engineering," says Peter Wells with CoCreate, "the CTO, or someone at a high level in the organization. This person can create a sense of importance and urgency in a project, and motivate members to incorporate the goals as early as possible."

Plan on who will run the system. A company has about three options here: buy the software and run it in house, select an ASP partner to host it for you, or participate in an online trade exchange.

A security-conscious manager or advocate may insist the system be run complete within company walls. This option may include additional servers and database software purchases. An overstretched IT department won't be elated with news that they have another system to administer. Fortunately, there are several solutions for this problem.

"An engineering department can get past the IT barrier by deploying the collaboration system in a hosted environment," says PTC's Saitz. Because most engineers have a browser, let the system run on the hardware of a third party. This is often called the application-service-provider model. The advantage is that implementation is fast, about 10 days according to Saitz, and the IT department has little involvement or capital investment. Using an ASP avoids additional purchases.

But how do you know whether to run the system in-house or outsource it? Traditional thinking has been that if you are with a small company, you outsource it. "That thinking is changing," says Saitz. "Large companies may have extended their IT resources, so they may initially choose to go with the ASP model to get up and running to gain collaboration's benefits. Then, with success and proof of productivity in hand, management can be approached to expand the IT department."

So-called trade exchanges provide another route to rapid implementations. "These exchanges or ASPs may cater to a particular industry," says Saitz. "For example, Exostar works with defense and aerospace companies, and Conferos works with moldmakers, plastic suppliers, and molding shops." And Covisint deals with the auto industry. There are others. The advantage here is that you get to test the system at minimal cost, usually on a subscription basis.

Expect a little training. Despite a browser's easy use, collaboration systems require some training, especially for administrative personal. "Project templates can jump-start a project by populating it with company-specific processes and best practices," says PTC's Saitz. "Administrators responsible for configuring templates may need training in the XML-based features, but those are fairly straightforward," she says.

For end users, training is minimal, and it usually comes from watching someone else in a meeting. If tasks call for more extensive training, it can be conducted online, often in a WebEx session. Because this company hosts online conferences, engineers attending a WebEx session stay at their desks and watch the demo through their computer's browser. They'll see another program's interface, and watch the cursor move and make selections. Control of the application can be turned over to the engineer so they can try it themselves.

For goodness sake, be on time. There is no such thing as being fashionably late to a collaboration meeting. The event is synchronized, so be prepared. Start the meeting at the scheduled time. "You wouldn't want to waste the time of 20 people," says Tom Morris, CIO of Aptec Technologies, a product-development company in Ormand Beach, Fla.

Measure something to gauge success. Most experts suggest selecting a metric or two that measures how things are today, how they will be in six months, and then a year. This will gauge the impact of the system on existing processes. "A lot of companies don't do this, which makes it hard to justify applying the technology on new projects," says Framework's Stockley.

Consider measuring man-days spent on a frequent task or the time it takes to go from concept to production drawings. "Another useful gauge has been the number of times information gets published," says Stockley. "Projects using the technology best find a lot of publishing occurs early in the process." When a team member puts information or an information change on the project-Web site, its said to be published. "The team can get information out to the organization earlier, which improves overall communications. A lot of changes moved from late in the process to earlier," he says. What's significant is not the number of changes, but when they occurred. The earlier in the process they happen, the more innovative the product is likely to be, and the higher its likely market return."

Another goal could be, for example, to reduce the scrap rate on a troublesome product. "In one case, a team dealing with a quality problem made it a goal to solve it by getting together online a materials expert, a manufacturing engineer, and the designer," says CoCreate's Wells. They succeeded.

The benefit to the company will be that instead of waiting two or three years to see an ROI for a big investment, you see results in as little as six weeks. That's a good return in any economy.

The good news, the experts say, is that spreading the technology to a wider audience in a company happens almost automatically. Team members often invite nonteam members to online meetings to observe the process. With easy-to-recognize benefits, experts say, the second person usually seeks a software license and begins using it on projects.

Almost to a person, the developers practice what they preach by using their collaboration systems to create their own products. One said that in the space of five months, they had been invited to six different projects. Most of the companies mentioned here have demos on their Web sites.