Engineers at Ethicon Endo-Surgery Inc. have an easy time motivating themselves for work each day. Most will admit to drawing great satisfaction from inventing new tools for minimally invasive surgery.
The Cincinnati-based Johnson & Johnson Co. has grown rapidly in recent years. Since 1993, when it adopted a team-based approach to engineering, the company has gone from a follower to a leader in developing products for endoscopic surgery.
Besides boosting market share, EE-SI’s expertise in managing teams paid off in another way: It earned the company top honors in this year’s Concurrent Engineering Award program. Cosponsored by CAD/PDM software vendor Structural Dynamics Research Corp. (SDRC) in Milford, Ohio, and MACHINE DESIGN, the Concurrent Engineering Awards recognize companies that successfully use concurrent engineering and automation tools to improve their competitiveness.
Also named in this year’s competition as a top finalist is Case Corp.’s Agricultural Products Div. in Racine, Wis., a manufacturer of agricultural and construction equipment. Both Case and EE-SI emerged as winners after a comprehensive judging process that included completion of a detailed entry form and plant-site visits by a panel of judges. Award judges hailed from MACHINE DESIGN, Innovative Development Associates, a Cincinnati-based management consulting firm, and SDRC.
It’s no secret that world-class manufacturers try to get close to their customers. EE-SI has taken this concept to nearly fanatical extremes. “Everybody who touches the product is considered a customer,” says EE-SI Staff Engineer Jim Voegele. “For surgical tools, that could include radiological technologists, surgeons, breast-care specialists, and groups within EE-SI itself concerned with packaging, quality, regulatory issues, and many other areas. They all have different perspectives that can be valuable to know about.”
EE-SI’s efforts at discerning customer preferences are well focused. Rather than just turning loose its engineers to pepper surgeons with questions, the company teaches development teams to listen first then ask the right questions — and to ask them in the right way. “We show our people how to gather data that will provide objective feedback,” explains Doug Fraits, a group team leader.
The company has institutionalized its methods of encouraging constructive feedback from customers. For example, surgeons who make suggestions about an EE-SI tool automatically get the improved replacement as soon as it becomes available. To ensure such feedback gets folded into development, the company recruits team leaders from the ranks of R&D and other functional areas. Even product marketing personnel report to them.
The development process now in place at EE-SI didn’t happen by chance, nor is it the product of harried developers defining procedures on the fly. “We discovered early on that the people who are responsible for getting stuff out the door shouldn’t be the ones to worry about processes,” says R&D Systems Development Manager Wendy Turner. “So we created special positions to teach process management.” Process managers now chair regular roundtable discussions with team leaders to discern how well the tactics in place are working. One outcome has been a formal document outlining design processes.
MEASUREMENTS ARE KEY
Metrics, like loaves of bread, can grow stale. That is why EE-SI regularly convenes a special team of group leaders, support partners, and others involved in product development to examine current measurements. One of their tasks is to decide whether the current metrics by which teams get measured still make sense. Corrective action reports, products released, resource allocations, and customer feedback issues have all, at one time or another, been used as process measurements. If teams find better indicators, old ones get jettisoned to make way for new yardsticks of performance.
“We are moving toward metrics to predict performance rather than to react to problems,” says R&D Team Leader Michael Boehm. “We also recognize that developers can view metrics as something that will be used against them rather than as a tool they can use themselves. It takes some work to get people past that feeling.”
Project cycle time is a vital statistic that EE-SI now monitors carefully. One early insight was that it made no sense to apply the same norms to all projects regardless of their complexity. Now, efforts revolving around technological breakthroughs get measured separately from others. For both kinds of projects, a support group provides tools and processes that facilitate speedy development.
There’s no question that top management ties product development closely to customer input. Product-development offices share building space with an expansive on-site teaching facility for surgeons and other medical practitioners. It is there that experienced and potential users can learn more about EE-SI’s products in a surgical setting. Some classrooms even come equipped with real-time video-conferencing hook ups to surgery procedures taking place in other parts of the country. Students can observe experienced practitioners use EE-SI’s tools and even bounce questions at them as surgery progresses.
EE-SI engineers themselves can, if need be, enroll in basic courses on human physiology on site. Between such course work and on-going customer classes, they can acquire insights into customers on a variety of levels by just walking down the hall from where they hatch their designs.
It would probably be an understatement to say that product-development reviews for Case Corp.’s MX Magnum tractor project sometimes got a little intense. “They could be gut-wrenching,” admits Development Director Kenneth Moehle. Among other things, the new tractor was supposed to feature an innovative operator interface that would do no less than revolutionize the industry. To make sure the MX delivered on this promise, some reviews ran for eight straight hours.
The Magnum team had crystallized the idea for the MX through what might be called a grueling series of interviews, 1,200 in all, with worldwide tractor customers of all shapes, sizes, and stripes. “We once looked at the tractor dealer as the customer,” says Moehle. “Now, we pay more attention to the person who actually writes the check for the product.”
Case developers spent the first 18 months of the project organizing information coming from interviews. These became the inputs for a quality function deployment study.
What then followed was an exhaustive QFD exercise run with input from Massachusetts Institute of Technology Professor Don Clausing. Credited with introducing QFD to the U.S., Clausing was duly impressed with the Case developers’ fervent efforts. “He said we probably went to an extreme on our QFD work,” says Moehle.
Clausing’s reaction should have come as no surprise. Case developers had performed QFD studies on not just customer needs, but also separate analyses on the whole tractor, tractor subsystems, manufacturing operations, and even aftermarket support. Developers additionally benchmarked QFD results for the tractor, engine, transmission, cab, axle, and chassis with manufacturers that included Deere, Ford, Fiat, Fendt, Massey Ferguson, and AGCO.
Despite a flood of positive feedback from customers, the project was not without risk. The tractor cab, for example, was an almost entirely new design that developers considered carefully. “You don’t do a program that is 65% new parts without some risk,” points out one Case developer. Tools such as Pugh diagrams and Failure Mode and Effect Analysis helped the team both identify items that were particularly risky and devise fallback strategies.
And there were false starts. At one point, developers practically rebegan anew on the cab design after a prototype got lukewarm reviews from a focus group. “We’d continually go back to the customer and ask whether the solution we envisioned was the one they had in mind,” says Moehle.
Developers also devised visual tools called Isorisk Contour Maps to help quantify risks at various stages of development. “A visual representation of risk is much better than just a simple list of items, particularly when you are trying to explain the situation to management,” says New Product Development Manager Fenton Harder.
Isorisk maps plot consequences against probability of failure for various design issues. Items that fall into the lower left quadrant are low risk. Items straying to the upper right are worrisome. Management could see movement down and left as developers found ways of mitigating issues. Stubborn problems that remained at the top right were obvious and got management attention.
“We used a single-sheet risk assessment to start and end meetings,” reports Harder. “The ground rule was that the person who wrote the problem report was the only one who could close it.”
Critical difficulties underwent a thorough root-cause analysis. By the time they finished, Case developers had addressed 2,700 problem reports of various kinds.
Such thoroughness paid off. In the middle of the project, the whole effort was accelerated to get a jump on competitors. The team’s risk studies saved the day, letting developers identify pressure points and critical schedule drivers. Though it involved making large capital investments earlier than originally planned, the effort picked up speed with few hitches.
The Magnum MX hit its scheduled launch date. Once the dust had settled, the development team had another plum to crow about. The tractor had been delivered within 0.5% of its projected cost, despite what could have deteriorated into a mad expensive rush at the end.
CASE’S TRACTOR-CAB COUP
An incident at a trade show gave developers on the Case Magnum team an early sign of just how big a hit they had scored with their new tractor. They watched gleefully as five engineers from their biggest competitor crawled into the cab and examined it as though they’d discovered a spaceship from Mars. The irony: No other tractor cabs in the industry were big enough to hold five engineers.
If competitors were caught flat footed by Magnum’s spacious cab design, it was because of Case’s extensive quality function deployment process. Case credits intensive QFD with giving developers insights into features that “wow” tractor buyers. The design of the armrest alone involved watching 100 hr of video taken of operators manipulating controls. Out of these studies came quantifications of human factors such as the average control use per hour, the amount of eye contact while using controls, and how operators oriented themselves in the seat and cab.
Ergonomic studies of 30 operators yielded further insights into seat control use, the best position for the throttle and controls under the armrest, as well as how best to configure the “reach” zone for power take-off and auxiliary controls. These studies also generated recommendations about laying out the instrument displays for easy reading.
Even the audio system got close scrutiny. Drivers gave it a thumbs up, and tests confirmed it performed 33% better than those in the five top-of-the-line pickup trucks used as benchmarks.
“People sometimes look at the thousands of hours spent on QFD and get impatient,” explains Case Development Director Kenneth Moehle. “They’ll say, ‘You’ve been in this industry long enough to know what to do, why can’t you just go into a room and figure things out.’ The problem with that is in hitting what’s important to the customer. It’s easy to produce bells and whistles that ultimately don’t matter much. QFD gives you the knowledge to do what’s right.”