Concurrent-Engineering

CONCURRENT ENGINEERING FOR CHALLENGING PRODUCTS

The most effective way to Design Products for Manufacturability

Concurrent Engineering is the most effective way to develop products with challenges for functionality, cost, time-to-market, quality, satisfying customer needs, meeting all growth demands. and designing products for all aspects of manufacturabililty.

THE USUAL SCENARIO WITHOUT CONCURRENT ENGINEERING

• Design the product for function, because there is no time, talent, or motivation to do any more than “just get something working” Base the design on whatever is known now about customer needs and market variations.

• Select parts for the functional prototype. Worry about availability, lead-times, and reliability later. For custom parts, design them quickly isolation, send them out for bid, and go with the low-bidder to throw something together quickly for a prototype.

• Build a prototype using the heroics of engineers or skilled technicians to temporarily overcome manufacturability and supply chain shortcomings.

• Stir up sales or contracts, using the working prototype. Use the prototype to get customer feedback.

• Then launch the product into production, after the sales or contracts come in

• If it costs too much, sell the early ones at a loss. Then:

• Assume that just getting the volume up will automatically get the cost down through mass production, “economies of scale,” automation or robotics. To read about the shortcomings of all these elixirs, see the Mass Production article.

• Pressure your people and suppliers to try to reduce cost later with change orders regardless of the effort and time required. Assume such changes will not compromise functionality or quality, or necessitate even more change orders.

• If customers have problems or want changes, dispatch the same people to deal with them, do damage control, and commit to the changes.

• Then try to ramp up production quickly using the very same people to, first, issue change orders to try to lower the cost, remedy newly discovered bugs, and make the product manufacturable before the window or opportunity disappears. Assume that there will be enough time and resources available to redesgn the products for manufacturability.

Sound familiar? How well does this go?

The above scenario is common, but may that may not be revealed in the news or benchmarking unless a high-profile product has performance problems, quality shortcomings, shipping delays, or misses its window of opportunity.

PROBLEMS AND RISKS OF THE NON-CURRENT SCENARIO

Shortcomings of designing only for function

Products designed only for functionality not only will be inherently deficient in manufacturability, quality, part availability, serviceability and all the other “.....ilities,” but such a limited design focus will probably make so many arbitrary decisions that it will be very hard to correct these later, without a complete redesign. Decisions made only for functionality will probably exclude the other considerations, which will result in the following consequences:

• A design-for-function product architecture will lock in most detail design and part choices, all of which may make it hard to add manufacturability later without a lot of effort and time, maybe necessitating a redesign.

• Then, once a prototype is built, all these decisions will be cast in concrete and boxed into so many corners that it will be very difficult, maybe impossible, to change the design for manufacturability, even if there was any extra time and resources to do it

• Such changes, in addition to being expensive, time consuming, and suboptimal, will “always degrade both product and process performance” which will add many risks and take even more resource-hours and time to mitigate those risks.

Problems cause by not understanding the voice of the customer

Schedules and resources are both at risk if the product designers do not fully understanding all the things that all customers really want. This process may start with the worst words heard in product development – “What you built is not what I want!” Without systematic product definition and a proactive strategy to deal with product variations, these will trickle in as many customer-induced changes, which cause delays and resource drains through the product development process.

Heroic prototype builds are unrealistic

Prototype technicians and engineers (who should be designing products) can often make an unmanufacturable design appear to work with enough heroics, but that may mask the manufacturability challenges that will delay the ramp to stable production and cause delivery delays of the stable production of qualified products or to contract completion. The NPD metric of “first customer ship” should be discarded because of risky temptation to build three and ship the one that works. In one of the author’s classes, a client said they build 300 and ship the 100 that work!
Even your best heros may not be able to overcome supply chain shortcomings when:

• purchased parts are selected only for function while ignoring availability issues, lead-time delays, system compatibility, and vulnerabilities for quality/reliability, all of which will delay volume production and limit growth, while demanding more resource-hours and calendar time to remedy.

• custom parts are designed without the help of vendors, who then face the dilemma of

• building a suboptimal design asked for in your bid request, which may lock it into the design

• asking for more time and bid exceptions to improve the part design

Overcoming fallacies about cost

First of all, there are serious consequences to postponing dealing with cost challenges or assume that cost will automatically come down as volume goes up. In reality, an unmanufacturable product will be impossible to automate and make it hard to make even to make simple tooling. In fact, the author’s Design for Automation guidelines have stricter design rules and supply chain constraints than his DFM guidelines. Further, parts selected only functionality usually:

• can be hard enough to procure that any expected economies-of-scale benefits will be replaced with expensive solutions to availability problems, like expediting, buying up obsolete part inventories, part changes, and redesigns.

• result in long lead-times that will delay shipments and limit growth.

Believing that economies of scale are the elixir for low cost might even encourage maximizing the contract quantity, but that will just compound all the issues cited in this section.

Example of cost fallacies in action. Economies-of-scale are a key cost strategy for the Concentrated Solar Power (CSP) industry. Instead of designing for manufacturability, they just negotiate the biggest projects they can, which actually makes them harder to finance, limits siting options, and increases many risks. Two CSP companies followed that strategy, after contacting the author but not following through with DFM. They have both gone bankrupt and the survivors are just waiting for more government subsidies.

Difficulties trying to reduce cost later

If the company signs a contract at reduced prices, it will be contractually obligated to attempt the cost reduction and make the changes. However, this is more difficult and less effective than assumed.
        Except for truly low-handing-fruit, which is rare, total cost be very hard – or impossible – to reduce after design and trying will waste a lot of resource-hours and calendar time. Many studies have shown that over 80% of cost is determined by the design and is very hard to remove later because designing the architecture primarily for function will probably exclude the biggest opportunities, that determine 60% of the cost. Then designing parts around such an architecture will lock out the big opportunities and limit part design opportunities to those that won’t change the architecture.
        Further, these attempts to reduce cost after design will raise other costs even more than the goals, especially if “cost” is defined mostly as part cost, which encourages substituting cheap parts and low-bid vendors. And trying this will consume even more resources and time to fix functionality and quality problems resulting from he cheap parts and low-bid vendors. The author’s 2014 DFM book has a chart that graphically shows the these costly consequences.
        The least effective and most damaging “cost reduction” strategy is yearly cost reductions. In addition to all the problems of the above cited reference, these efforts will be even more limited to substituting cheaper parts and vendors, to existing working designs, thus putting their functionality and quality at risk and maybe necessitate requalifications.

Example of the wrong approach to cost: The slogan in the commercial aircraft industry is:
“Get a plane in the air quickly so we can sell it; You have 30 years to get the cost out!”

Changes may force a requalification

Too many changes to remedy functionality and quality problems may require requalifications, which will consume even more resources and significantly delay the production of qualified products.

Accumulating deferred problems

Unfortunately, the above problems can accumulate and converge, like a”time bomb “ at the worst possible time – when operations and SCM are scheduled to produce reliable, qualified products in the quantities that will satisfy contracts or sell enough to capture the window of opportunity.

THERE IS A BETTER WAY: CONCURRENT ENGINEERING

Using Concurrent Engineering to designing for everything (DFX) doesn’t take any more time or cost. In fact it is the key to half cost products (which is the focus of the author’s website: www.HalfCostProducts.com) and cutting in half the time to customer acceptance or stable productions of qualified products, as discussed below.

The opening comments in the Chapter 2 of the author’s DFM book defines Concurrent Engineering as:

Concurrent Engineering is the practice of concurrently developing products and their manufacturing processes in multifunctional teams with all specialties working together from the earliest stages.

USING CE TO DEVELOP CHALLENGING PRODUCTS

After understanding what customers want, project management must commit to avoiding the above scenarios and their consequences. The process starts with optimizing (1) team participation and (2) the project timeline. Everyone involved in product development and its management will have to overcome the apparent paradoxes, which will be shown graphically below:

A higher proportion of resources up front will save many more at the end

A higher-proportion of calendar time up front will save much more at the end.

1) Team Participants

        To avoid the above mentioned consequences of function-dominated design, project management must identify multi-functional resource needs to assure participation of Manufacturing, Supply Chain, Quality, customer liaisons, and regulatory compliance;
        Subsequent sections, below, will delineate what teams should do in the crucial up-front stage and in the design stage.
In order to assure these people are available with enough bandwidth to make meaningful contributions, key people should be assigned to the project, paid for by the project budget, and protected from being drained away for reactive tasks, like the firefighting and change orders to rectify the problems mention above. The following graph shows two time lines: the typical back-loaded profile and the advamced concurrent model. This is Figure 2.1 in the author DFM book

As shown in Figure 2.1, the traditional product development time-line gets off to a bad start with a vague understanding of customers’ needs. Typically, only a few people are available at the beginning, either because of resource availability problems or by choice because project management doesn’t appreciate the value of complete teams. In some cases, product development begins with a small clique because of downright exclusivity or because some elite people think that “DFM starts “after they are finished.”
        Whether or not deficiencies in the team composition are acknowledged, schedule pressures usually force the “team” to make some “progress.” And, a key element of making progress is making decisions. However, without the benefit of a complete team, the decisions will probably not address all the considerations discussed above. This problem will be even worse if there is no diversity among the people involved, for instance, if everyone works in the same department and has the same education and experiences.
        Unfortunately, without a complete team, many early decisions will be arbitrary, which is especially problematic as these arbitrary decisions then become the basis for subsequent decisions, or limit them, which in turn, will have even fewer open options. After several levels of subsequent arbitrary decision making, the product architecture becomes “cast in concrete,” which makes it very hard to optimize or correct later
    As shown in Figure 2.1, the traditional product development time-line gets off to a bad start with a vague understanding of customers’ needs,
Typically, only a few people are available at the beginning, either because of resource availability problems or by choice because project management doesn’t appreciate the value of complete teams. In some cases, product development begins with a small clique because of downright exclusivity or because some elite people think that “DFM starts “after they are finished.”
        Whether or not deficiencies in the team composition are acknowledged, schedule pressures usually force the “team” to make some “progress.” And, a key element of making progress is making decisions. However, without the benefit of a complete team, the decisions will probably not address all the considerations discussed above. This problem will be even worse if there is no diversity among the people involved, for instance, if everyone works in the same department and has the same education and experiences.
        Unfortunately, without a complete team, many early decisions will be arbitrary, which is especially problematic as these arbitrary decisions then become the basis for subsequent decisions, or limit them, which in turn, will have even fewer open options. After several levels of subsequent arbitrary decision making, the product architecture becomes “cast in concrete,” which makes it very hard to optimize or correct later

Figure 2-1 Team Participation: Traditional vs. Advanced Models

         Continuing to follow the sequence in the top graph of Figure 2.1, what is perceived to be a “complete” team eventually forms, but it is not as complete as recommended herein. The team may proceed for a while in a state of naive contentment, but eventually there will have to be several redirections because of the inadequate product definition, customer-induced changes, or because of the arbitrary decisions made by an incomplete team. So then more effort is expended, possibly with more people added, because the project is starting to get “in trouble.”
    After the above redirections and delays, the project is now “behind” (probably set arbitrarily) so the work needs to be “accelerated.” This is so common that one product development book even has a chapter titled, “Throw Money At It” based on the thinking that time is more valuable than money at this point.
    Then come the prototype surprises, which are the inevitable consequences of an incomplete team, cumulative arbitrary decisions, and failure to address all the design considerations like manufacturability.
Work then proceeds after many fire-drills to try to correct problems and get the prototype to work. Of course, one prototype is not a statistical significant sample, so real life production problems could be worse than indicated by a prototype.
    Then the typical project encounters serious DFM shortcomings only as production ramps approach. If DFM was not designed early in the product, it will probably be very difficult to make the product manufacturable through changes at this late a date. Faced with the formidable scope of implementing DFM by change order under intense time pressures, only the easy changes are pursued and production soon begins on a product with questionable manufacturability.
As the product goes into production, manufacturability shortcomings manifest as painfully slow ramps (shown in the center graph in Figure 2-1), sometimes taking months to reach the target production volume. Manufacturability problems also show up as poor quality and disappointing productivity which may take even longer to attain acceptable levels. Not only do these delays and shortcomings disappoint customers, but they also consume a great deal of resources – resources that should have been utilized more wisely at the proactive beginning, not the inefficient reactive end of the project. This, of course, emphasizes the importance of measuring time-to-market to the time of full stabilized production.
    Most of the attendees queried in the author’s seminars admit that many elements in this sequence are quite familiar, many painfully so.

The Advanced Mode

        In the Advanced Model in Figure 2.1, all the relevant specialties are present and active early. If each team member has a versatile background and can represent multiple specializations, then the team would be smaller and easier to manage.
The complete team is formed at the very beginning to simplify concepts and optimize product architecture and the thorough up-front work that is discussed below..
        In addition to the full-time core team are vendor/partners and part-time specialists for specific tasks such as socialized analyses and regulatory compliance.
        The activities start with a methodical product definition. After the Architecture Phase is thoroughly optimized, the remaining workload actually can drop off because of the thoroughness of the up-front work, vendor/partners help design custom parts, and previous modules can be utilized or the design of new modules can be shared with other projects.
The result is that the volume ramp is completed quickly. Similarly, normal quality and productivity targets are reached rapidly. One important result is the ability to cut in half the real time-to-market as measured to stable production. The other equally important result is that the cost of resource-hours (the areas under either curve) is half compared to the traditional model.
        Companies on the upper time line need shift from a back-loaded model to front loaded one. Section 2.2 of the author’s 2014 DFM book shows 19 ways to solve resource availability problem, the most effective of which are Prioritization (Section (Sections 2.2.1 through 2.2.9). The most immediate way to make resources available for a new project is to avoid wasting resources trying to reduce cost after design.

The consequences of inadequate resources at the beginning are
significant delays and wasted resources,
which in turn will delay other projects and deplete their resources,
while expending more development cost for all projects

2) Project Timeline has higher proportion of up-front work

The second step is to assure the project time-line has a high enough proportion of up-front time to assure that the project has enough time do Concurrent Engineering. Thorough up-front work greatly shortens the real time-to-market and avoids wasting time and resources on firefighting, change orders, and ramp problems, as shown in the top bar of Figure 3.1 in the author’s DFM book.
` This is the “Lexmark” model, from the company that spun off from IBM’s printer factory in Lexington, KY. The author first saw that graph in a Sematech presentation to the semiconductor equipment industry, which indicates its value for the development of challenging products.

Figure 3.1 Traditional vs Front-Loaded Time Lines

The main messages from the Figure 3.1 graph are

a) Spending only a few percent of the top timeline on the product concept/architecture phase causes three-fourths of the total effort to be spent on revisions, iterations, and problems ramping up to production.

b) However, thorough up-front work (in the lower time-line) can cut the real time-to-market in half because it is much easier and faster to optimize the design with early teamwork than later with change orders.

c) No significant delays in alpha and beta units occur, since the design phase proceeds quicker after thorough up-front work so it is finished about the same time in either time-line.

Do not offer or accept management or customer-specified
intermediate deadlines that would compromise thorough up-front work.

Thorough up-front work is the most important principle to reduce the real time-to-market. Which is the time to stable production in the center graph in Figure 2.1.
This graphic, and its profound implications, generate much discussion in the author’s in-house DFM training. In fact, a commercial airplane manufacturer spent one hour discussing this graphic at all four seminars.

The Thorough Up-Front Work

As engineers and managers realize the importance of thorough up-front work, they ask what more should be done in the higher proportion of work in the “concept/architecture” phase and how this can actually reduce the end of the time-line so much. The key elements of an optimal architecture phase are the following:

• Good product definition defines what customers really want and minimizes the chance that may result in change orders to reflect “new” customer needs that should have been understood and anticipated in the beginning.

• Validate assumptions. Understand, scrutinize, evaluate, challenge, and vet assumptions, especially those that will commit the project to a certain path. Revisit assumptions as you revisit ideas, concepts, and approaches, which is one of the “Nine Keys to Creativity.” .

• Diverse opinions are sorted out early with respect to diverse data about customer needs and
and project assumptions.

• Regulatory compliance. Develop compliance plans for current/known regulations and identify likely scenarios regarding potential regulatory changes, commissioning research as necessary. Categorize changes that would force a requalification, especially customer-induced changes and changes needed for manufacturability. Based on that, formulate plans to minimize customer changes in the first bullet above and use Concurrent Engineering to design the product for manufacturability, using the steps below.

• Early teamwork amongst people in Engineering, Manufacturing, Quality, Supply Chain Management, Service, and customers themselves to concurrently address, resolve, and optimize the above activities in frequent interactions, not asking for “input” or discussions in period reviews or gates.

• Concept selection and early development of functional concept that will be assured in production environments, with anticipated production line people and readily available parts and materials. Concepts should be generated with clever, practical innovations for the product, processing, and optimal modularity to handle anticipated variety. Be sure not to base concepts on unrealistic tolerances, or overspecify tolerances just to ensure that a proof-of-principle “works,” after which the tight tolerances may never be released.

• Lessons learned. With the multifunctional team in place, the next step is to understand the lessons learned from previous or similar product development efforts. This will show the team what worked and all the things that cause problems and delays, as shown in the upper bars in both of the above charts. Lessons learned should be thoroughly investigated and understood to learn what worked well and what caused problems in previous projects (see Section 3.3).

• Issues raised and resolved before proceeding further, thus minimizing:

(a) requiring expensive, risky, and time-consuming work-arounds on every build, or

(b) the chances that these issues will have to be resolved later when changes are expensive, hard to implement, and may, in turn, induce yet more changes.

• The architecture should be optimized for the minimum total cost, for designed-in quality and reliability, for manufacturability, serviceability, and for flexibility and customizability. The architecture may need to be optimized for product families, variety, extensions, next generations, contingencies, and growth.

The Design Phase Considerations and Methodologies

With the thorough up-front work done right, the actual design phase can proceed quickly and smoothly, in half the usual time, as shown in Figure 3.1, and half the usual resource-hours, as shown in Figure 2-1.

• Vendor/Partnerships should be arranged to preselect vendor/partners. According to the authors of the book that started the Lean Production movement in the U.S., “the best companies studied, vendors “are not selected on the basis of bids, but rather on the basis of past relationships and a proven record of performance.”
        Vendor/partnerships are the most efficient way to ensure the manufacturability of custom parts with concurrently designing tooling, thus minimizing ramp delays. They effective expand the size of the ign team without hiring any more employees or reassigning them from other projects. This also avoids losing your scarce resources to deal with problems cause by low-bid vendors or vendors who just build-to-print whatever your sent them in a request-for-quotation.
        And, contrary to common beliefs and policies, vendor/partnerships will actually lead to a lower net cost (Section 2.6.2),
Industry Week's "Best Plant" survey of the 25 top performing candidates found that 92% emphasize early supplier involvement in product development.
        Chapter 10 in The Toyota Product Development Process, is titled: "Fully Integrate Suppliers into the Product Development System,"

Use these principles to strive to be your customer’s vendor/partne.

• Tooling and processing development should be started early in which all potential concepts have enough concurrent engineering to vet potential production approaches for feasibility and assure adequate production and supply chain capacity will be achieved without delays for tooling problems. Don’t wait until the part is designed to start thinking about fixtures and tooling concepts.

• Part and Material availability can be assured by selecting them for availability, not just function. Section 5.19 shows how to select parts for availability throughout the life of the product and avoid the problems of long-lead-time parts.
Basing production designs on hard-to-get parts, which may have been selected for a proof-of-principle, may compromise order fulfillment and ultimately limit growth. Selecting parts for available needs to be done all along because availability problems are hard to remedy after qualification.

• Tolerances are appropriately tight and consistently achievable at low cost and fastest throughput. Avoid basing research on excessively tight tolerances that carries into production and gets locked in by qualifications
• Skill Demands. Never exceed the capability of production-line workers in your plant or contract manufacturers. Avoid building proofs-of-concept that can only be built by highly skilled scientists, engineers, or prototype technicians because once approved, qualified, and put into production, high skill production-line workers will be needed, who may be hard to find, train, and retain, and may limit growth. Further, if not managed really well, dependence on skilled labor may cause quality vulnerabilities. raise cost, and delay the launch.

• Off-the-shelf parts. Design teams should focus their valuable resources on the crown jewels, which are what customers will buy your products for – and get the rest off-the-shelf, whenever possible. For example:

Customers buy electronic products for the unique, innovative features and functions they accomplish, not routine computations, controls, communications, and power supplies that are just expected to work reliably.

Customers buy mechanical products for the unique, innovative structures or motions they do, not routine motions, controls, enclosures, and structures that support the crown jewels and work reliability.

What is needed from these routine support parts is adequate functionality, assured availability at any volumes, no risk, and high quality and reliability. Proven off-the-shelf parts can quantitatively assure all of these from their “track-records” which is not the case from custom-designed parts that introduce many variables, unknowns, and risks.
But, despite these opportunities, most design teams do not even consider off-the-shelf parts because of the following inhibitions that can be set straight by these principles:

• Just because a product is leading-edge doesn’t mean all the parts have to be custom. In fact, the product will be better if everyone focuses on what is really leading-edge.

• Some teams may not do a thorough enough search or not even look for “better” OTS parts, assuming they will cost more. However, the total cost may be less because of the all the costs of developing and debugging the “just right size” version. If “better” is larger or heavier, this may be a consideration in aerospace, but may not be a factor for miniaturized parts like electronics.

• OTS parts may appear to cost more than in-house built parts because OEMs pay total cost for them, but in-house parts don’t include all the overhead costs because they are rarely quantified.

Bottom line: if OTS parts are not considered early enough, then arbitrary decisions preclude their use – for example, if circuitry is designed with too many voltages, that may preclude reliable off-the-shelf power supplies.

The paradox of off-the-shelf parts is that designers may have to first choose the best off-the-shelf parts and then literally design the product around them. But it may be worth it to focus finite resources and time on your crown jewels.

• Standardization. Until a company or division effort establishes standard parts lists (Chapter 5), the project should standardize on key parts for the product, at least for the following categories before detailed design starts:

• Fasteners, which usually proliferate wildly if designers specify the just-what-is-needed size for all needs. To curtail this proliferation before it starts, project management should select a baseline list of standard fasteners for the needed sizes, loads, and environments, for instance: “small, medium, and large, and maybe one or two in between.” As in all standardization, most applications will get a “better” part than needed, but no one should resist standardization because it raises a BOM entry slightly because the total cost savings will be much greater.
For instance, all bolts should be standardized on the strongest grade. This provides automatic mistake-proofing (Poka-Yoke) benefit by preventing a weaker bolt accidently being used where a stronger bolt should have been used
For small parts, like fasteners and integrated circuits, there would be minimal, if any, weight penalty for such standardization.

• Expensive or hard-to-get parts. Standardizing on expensive parts is one of the solutions to eliminating long-lead-time part problems, which can enable steady flows of parts that will be used one way or another, borrowing from others users in emergencies, and even stocking the standard versions, none of which would be possible for a plethora of just-the-right-size versions. More advanced or higher capacity parts may weight more or take up more space, but that may be cancelled out if the more advanced part combines parts that would otherwise be many discreet parts.

The bottom line is that standardization will:

(a) help ensure part availability by design for peaks in demand, and for growth.

(b) greatly improve serviceability, repair, and maintenance while minimizing the cost and maximizing the usefulness of spare parts kits..

(c) all of these benefits will result in net total cost savings to justify some applications betting a “better” part than needed.

Designing Products for Manufacturability

Everything discussed above is essential to design for manufacturability. But many courses and books only present design guidelines (which is the next section) or just analyze the product after it is designed to look for opportunity to combine parts (originally Design for Assembly now this is called DFMA). Unfortunately, many engineers and managers have taken one of these narrow courses, and resist advanced training and books, because they may have already “had DFM.”

Design Guidelines

        Design teams need to understand and obey design guidelines, which can be found in handbooks, like the Handbook of Product Design for Manufacturing; and SME’s Tool and Manufacturing Engineers Handbook, Volume 6, on DFM, which is available digitally, but may not be available in print. The author of this while-paper wrote the opening chapter in that handbook. Both of these books have a chapter on designing for every manufacturing process.
        Another source of guidelines is the author’s DFM book, which has 27 general guidelines on product design in Chapter 8 and 51 part design guidelines in Chapter 9. . The are summarized in this site's DFM article.
        Of course, the ultimate approach would be for designers to know these general design guidelines and work early with preselected vendor/partners, as mentioned in the first bullet in the Design Phase section above.

Team interactions should be frequent, on-demand

Consulting firm A. T. Kearney wrote in Industry Week about the typical rigid processes for new product development:

“Most companies have well-established product-development processes that are highly rigorous with fixed tollgates, multiple interim milestones, and reviews to ensure that product development is on track and on budget. This approach, while inherently sound, contributes to a lot of inefficiency and lack of speed while adding additional cost elements.”

This article is posted at: http://www.industryweek.com/articles/driving_growth_through_ultra-low-cost_product_development_21154.aspx

Instead, A.T. Kearny say that in order to “minimize the amount of post-design-freeze changes,” the process should instead require more frequent cross-functional meetings. Concurrent Engineering calls these on-demand meetings, huddles (next topic)

At IDEO, the CEO, Tim Brown, says: “Good ideas rarely come on schedule and may wither and die in the interludes between weekly meetings.”

On-demand huddles

Rather than trying to do Concurrent Engineering in scheduled periodic meetings and many formal reviews, team members should be continuously working together and calling huddles to make decisions and resolve issues as they need to be addressed. Thus, the design is continuously “reviewed” more effectively early and often. People inside and outside the team should huddle on-demand for information sharing and quick decision-making, rather than accumulating issues for an event.

At Ford’s successful 2009 skunk-works project that quickly developed the new “Scorpion” diesel engine: “We saved months by knowing hourly what the other guys were thinking and what their problems were.”

The Project Room (The “Great Room” or Obeya)

The fastest, most effective way to implement CE is to create a microclimate in which a multifunctional team can implement all these principles right away in a dedicated project room (Obeya in Japanese) for each project to accommodate spontaneous “huddles” and display the team’s charts, graphs, drawings, experiments, samples, models, prototypes, and so forth. Not having this would discourage spontaneous discussions, simply because of the lack of availability of somewhere to meet.

In Toyota culture, “The Obeya integrates various product development participants throughout the life of a program” facilitating meetings several times a week, which “enable fast decision making and information sharing.”
The team and the team leader (chief engineer) meet almost daily in the Obeya to make decisions in real time, not waiting for periodic meetings. “Usually, once every two days at least the whole team assembles there.”

At IDEO, “we have dedicated rooms for our brainstorming sessions, and the rules are literally written on the walls.” “The simultaneous visibility of these project materials helps us identify patters and encourages creative synthesis to occur much more readily than when these resources are hidden away in file folders, notebooks, or PowerPoint decks.”

If project room space is not readily available, fully understand that the business model should determine the facilities planning, not the other way around.

SUMMARY NOT CONCURRENT ENCINEERING CAN HELP DEVELOP CHALLENGING PRODUCTS

Compared to a narrow design focus with multiple handoffs, thorough up-front work will ensure much faster design for successful functionality and early multifunctional teamwork will result in better functionality.

Further, quality and functionality itself will not be compromised to make many late changes for manufacturability, late customer changes, dealing with low-bid vendors, and desperate attempts at cost reduction after design, followed by correcting the problems of late changes, which "always degrade both product and process performance"

Without Concurrent Engineering, order fulfillment and growth will be limited by the need for highly skilled heros, long lead-time parts, or not enough part or material availability to keep up with demand. The real “time to market” will be greatly delayed if requalifications are need for all these changes.

And developing an efficient product development process without all the resource drains will enable highest return/effort of product development resources.

About the Author

Dr. David M. Anderson has been providing customized in-house seminars on DFM and Concurrent Engineering for 25 years. Seminar/workshop engagements include eight at Hewlett-Packard, five at GE, four at Boeing, four at BAE Systems, four at Smiths Aerospace (now GE Aircraft), four at Korea's LG Electronics, three at Ball Aerospace, three at L-3 Communications, three at FMC, two at NCR, two at Emerson Electric, two at Freightliner, two at John Deere, and two at United Technologies Corporation.
His military service was as an officer in the US Army Air Defense Artillery. His first job was for a government contractor (later acquired by BAE Systems) that developed remotely controlled ground vehicles, manipulators, and bomb-disposal robots.
Since 1990, he has published books on DFM and Concurrent Engineering, with updated editions published every couple of years, based on his seminars, webinars, workshops, consulting, and, before that, his experience starting the DFM program at Intel for circuit boards and single-board computers, On his first day at Intel, he attended IBM;s DFM class. In 1993 he twice taught the Product Development course at the Haas Graduate School of Business at U.C., Berkeley.

Dr. Anderson is a Fellow of the American Society of Mechanical Engineers and a Life Member in SME. He has been certified as a Certified Management Consultant (CMC) by the Institute of Management Consultants. His credentials include professional engineering (P.E.) registrations in Mechanical, Industrial, and Manufacturing Engineering and a Doctorate in Mechanical Engineering from the University of California, Berkeley.

These are the general principles. Pass around this article or URL to educate and stimulate interest

In customized seminars and webinars, these principles are presented in the context of your company amongst designers implementers, and managers, who can all discuss feasibility and, at least, explore possible implementation steps

In customized workshops, brainstorming sessions apply these methodologies to your most relevant products, operations, and supply chains.

The very first step may be to start with a few hours of thought-leader consulting
to help formulate strategies and implementation planning.

For an email discussion on Concurrent Engineering by phone ot e-mail, fill out this form:

Name

Title/Position

Company/Division

Location

Phone number

e-mail address

Type of products

Other challenges, goals, and opportunities:

To Submit, first enter "12" and hit "Enter" to bypass Robo Filter (required field)
i

Dr. David M. Anderson, P.E., CMC
fellow, American Society of Mechanical Engineers
www.design4manufacturability.com
phone: 1-805-924-0100
fax: 1-805-924-0200
e-mail: anderson@build-to-order-consulting.com