“The old premise of concurrent engineering has failed to cut time-to-market or boost quality.”

So says Michael N. Kennedy, an authority on the redesign of organizational processes. Kennedy is one of a handful of management experts who have studied how Toyota develops products. The reason: Toyota can push out a new product in much less time than its competitors, a feat that makes it a world-class developer.

One conclusion increasingly drawn from Toyota’s system is that many U.S. manufacturers have gone off track with their own development efforts. In fact, some of the processes they’ve adopted in the name of speed and quality have actually had the opposite effect.

“A lot of companies put in numerous administrative tasks which supposedly get you quality, but they don’t have a process which generates quality from the start,” says Kennedy. “It’s not uncommon to see Six Sigma procedures embedded in a huge product-development process. Product development just doesn’t work that way. At Toyota, quality is simply ingrained in the way they think and the way they work.”

One way Toyota gets an edge in quality is by approaching product development as two separate stages. The first stage, often dubbed the fuzzy front end, serves as a means for coming up with several wide-ranging design options.

“At Toyota product development isn’t so much about developing products as it is about developing knowledge about the product. Do this right and quality products emerge naturally,” says Kennedy.

The term that has emerged to describe what goes on during the fuzzy front end is set-based concurrent engineering. The moniker refers to the process of exploring multiple sets of possible design alternatives, all aimed at broad goals. The connections between subsystems devised in the beginning stages are loose to give developers flexibility in how they approach specific problems.

It was the failure to distinguish between set-based front-end work and detail design that was responsible for a lot of failed concurrent engineering efforts, Kennedy says. “Developing the manufacturing process plans at the same time you do the design often results in a lot of expensive tooling that just gets thrown away,” he explains. “That’s because the design isn’t stable yet. Instead, you need manufacturing and engineering jointly deciding on trade-offs in the early stages. It is only once you’ve finished the resulting sets of trade-off curves that it is OK to do process planning and detailed design simultaneously.”

The set-based philosophy includes producing redundant systems as backups. An example comes from Durward Sobek, associate professor and graduate program coordinator of industrial & management engineering at Montana State University. Sobek says Toyota typically maintains at least two full-scale models in parallel. Simultaneously, Toyota engineers develop structural plans for multiple styling design ideas and analyze them for manufacturability.

Sobek also says Toyota tends to stay as flexible as possible until relatively late in the development stage. He cites as an example Toyota’s practice of leaving manufacturing tolerances to be set by die makers rather than by design engineers creating the prints. Die makers make die dimensions as close as practical to those in the CAD database, but have the flexibility to modify them so body parts fit together well. Manufacturing engineers then set tolerances around manufacturing capabilities.

In contrast, many U.S. firms freeze their basic design early in the cycle, experts say. The result is often a lot of drastic and time-consuming revamping before components and systems are ready for production. Michael Kennedy cites as an example the practice of devising CAD models of proposed products which then go through finite-element analysis. The feedback from analysis can result in fixes to the design. “Toyota would say this is absolutely backwards,” says Kennedy. “You have designed the thing and are looping back to fix it. So your development is about quickly coming up with a design and then seeing whether or not it can be fixed.”

The Toyota paradigm is the reverse of that, Kennedy says. “Test first, then design. First run simulations and understand where the boundaries of solutions lie. Once you understand the alternate spaces between competing choices, you narrow the options in what are called integrating events.”

Integrating events are an opportunity to eliminate weak opportunities. It is only after these events are complete that detailed design commences. “The point is that you don’t get to detailed design until everything works,” says Kennedy. “That is the reason Toyota focuses so intently up front on understanding trade-offs.”

The Toyota approach fundamentally attacks the so-called fuzzy front-end in development and forces engineers to view follow-on steps in the process in a different light. “You don’t think in terms of a geometric model. You think in terms of the range of customer interests, what you can do to meet them, and where you have gaps in your knowledge,” says Kennedy. “You can focus on closing the gaps and finding the limits of your solutions.”

The set-based approach
Use of the set-based approach, claims Kennedy, generates many more alternatives than does the conventional practice of focusing on a single approach early in the cycle. “It gives engineers a wealth of understanding about what they can and can’t do. And these efforts always give them a backup design,” he says.

And adopting a set-based approach is not like learning to speak Chinese. Kennedy says the beauty of Toyota’s methods are that they come naturally to engineers. “Companies do indeed have the knowledge you find in those trade-off curves. But more often than not, the knowledge lies only in the heads of their best engineers. Toyota has simply tried to turn what is intuitive to top engineers into the standard way of capturing information about the design,” he says.

The multiple alternatives generated during Toyota’s front-end work come together at integrating events. These events contrast with the phase-gate reviews many companies conduct during development. “Phase gates are basically reviews of compliance tasks. A gate usually is a check to see what you’ve done and what must happen next. But Toyota doesn’t care about defining specific tasks,” says Kennedy. “They start with a wide range of targets that lead to customer interests. These get refined through the integrating events. So individual teams are developing their knowledge to meet at those integrating events. You are not doing detailed scheduling at this point because you are engaged in something that is more of a learning process.”

Nevertheless, casting a wide net during initial project phases doesn’t always make sense. “Toyota’s approach has the most power in consumer products where there is a great deal of subjectivity,” explains Ron Mascitelli, educator, author, and consultant on lean development practices. “When you are dealing with a precisely defined volume or you are interfacing with a thousand tubes and wires, there is often not a lot of wiggle room for a wide funnel in the beginning. Those things are already defined for you by the environment. The value added from a wide-funnel approach is not worth the time spent in those cases.”

And once events progress into detailed design and CAD geometry, Toyota’s procedures resemble those of industry at large. “When Toyota starts this stage, they really think they are moving into production,” says Kennedy. “At this point phase gates work just fine, as does concurrent engineering. When you get to this point of detailed CAD, Toyota isn’t much different than anybody else.”

Something to emulate
Though Toyota is adept at developing products, it may be a mistake to adopt its practices wholesale, no matter how good they are.

“Much of the lean community tries to crow-bar Toyota’s approach into their own very different business model,” says Ron Mascitelli. “Toyota has already solved many of the tactical problems in day-to-day work flow, team communication, and risk management. And because their business is automotive, they can afford to dedicate hundreds of engineers to one new car model. But most companies have smaller teams working on many products. Toyota’s strategic vision is much harder for a company having different product lines each with a lot of diversity.”

All in all, he says, Toyota is a tremendous inspiration and other companies will find a number of its development tools valuable. “But you should select the tools you need. Logic tells you to start with the things that are wasting the most time and resources.”

The number-one time waster, according to Mascitelli, is a chaotic work environment. “Engineers often try to fit work in between meetings and walk-ins and fire fighting. We’ve done time studies that show typical design team members putting in only two hours a day of valuecreating work,” he says. Poor prioritization of work exacerbates these problems. “People often don’t know what their most important task or project is,” says Mascitelli. “So team members will concentrate on what seems right at the time. This might be what is interesting rather than what is important.”

Chronic work overload contributes to these difficulties. “This is particularly true among small to medium-sized firms. They don’t have teams dedicated to major new product releases. When you get an engineer working on five or six projects without clear priorities, the setup and changeover time to go from one to another is overhead that doesn’t create any value,” says Mascitelli. “He or she is just treading water. The rule-of-thumb goal is two projects per design engineer with no more than one of them having a clear priority. Among the companies I’ve worked with, this single policy change has made a major difference.”

But the biggest way to not waste time is to avoid working on the wrong concept. “You can develop a lot of products rapidly and have all of them be market failures,” says Mascitelli. “Casting a wide net initially forces teams to look at a range of design alternatives, then merge them and weed out the weak ones. This way, when you move into detail development and the lion’s share of the labor, you have the sense you’ve picked the right approach.”

Toyota has several tools that help its engineers organize the tasks at hand. One of the most well known is called the A3 document, named for the size of the paper its information is written on. An A3 holds a distillation of project goals and customer wants. During development, it can serve as a crib sheet for engineers as they set priorities and make trade-offs. “A3s enforce the plan-do-check- act methods of quality,” explains Kennedy. “The A3 becomes the basis for Toyota’s entire review process.”

“An A3 is a concise summary of when things must be done and what has to be done. It gives a vision that can’t be matched by thousand-line Gantt charts,” adds Mascitelli.

“There is nothing magical about an A3,” says Montana State University’s Durward Sobek. “It just helps facilitate learning and coming to an agreement.”

A3s, in fact, can be used for problem solving, as a documentation tool, and for planning. “The problem- solving format for A3s guides you through the process of defining the problem, gathering data to quantify the extent of the problem, establishing appropriate targets, identifying the root cause, investigating countermeasures, putting together an implementation plan, and follow up. You use it to talk with people who might be affected by what you propose to do. Eventually you use it to document what you have accomplished and to see if you hit your target,” says Sobek.

Sobek is an authority on A3s, having written a book on the subject after studying Toyota’s development practices. Though the ideas behind the A3 are straightforward, they often come as revelations to organizations that adopt them as problemsolving tools, he says.

“At one hospital I worked with, there were no meta routines for addressing problems. So they would default to highly individualistic problem-solving methods,” says Sobek. “One problem there was the inordinate time it took to move a patient from one end of the hospital to the other. The solution administrators tried was to just chew out the transporters for not working hard enough. Using A3s, we followed the transporters around and found, among other things, lack of communication was slowing things up — patients would still be hooked to monitoring machines when the transporters showed up to move them, for example. In this case the A3 was a means of getting to the root cause and helped cut transport time from over an hour to about 10 minutes.