HALF THE TIME TO STABLE PRODUCTION

The figure below graphically shows a “front loaded” Advanced Model (in green) that was completed in half the time to stable production, compared to the upper graph, which shows Traditional Team Participation (in red) - From the book "Design for Manufacturabililty & Concurrent Engineering, 2010¹.

The product development benchmarking reported by Womack, Jones, Roos in the first lean production book, “The Machine That Changed the World, The Story of Lean Production,” summarized the difference between the best and worst product development practices they encountered.

In the worst projects,           

“the number of people involved is very small at the outset but grows to a peak very close to the time of launch, as hundreds or even thousands of extra bodies are brought in to resolve problems that should have been cleared up in the beginning.”

Unfortunately, it is very common for a small inner clique to start designing without:

• Clear and relevant customer requirements

• Complete multifunctional team with all specializations active early

• Focusing on simplifying the concept and optimizing the system architecture

• Raising and resolving issues early, when it is easy, as opposed to later, when it is hard.


In the best projects,

“the numbers of people involved are highest at the very outset. All the relevant specialties are present, and the project leader's job is to force the group to confront all the difficult [issues] they'll have to make to agree on the project.”

   This comparison between the best and the worst coupled with the author’s experience with companies practicing both of these extremes inspired the following plot of team participation over time (with colors matching the Womack quotes), which graphically shows this vivid contrast between what will be designated “traditional” and “advanced” models.

  The traditional product development gets off to a bad start with a vague understanding of customers’ needs, with the production definition based on technological advancements, whims, or previous or competitive products. 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” (which was actually said by one physicist).

    Whether or not deficiencies in the team composition are acknowledged, schedule pressures will force the “team” to make some “progress.” And, a key part of making progress is making decisions. However, without the benefit of a complete team, the decisions will probably not address all the considerations. 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, 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.

    Continuing to following 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 some form of redirection because of the inadequate product definition or because of the arbitrary decisions. So then more effort is expended, possible with more people added, because the project is starting to get “into trouble.”

    By the time cost estimates are generated, word gets out that the cost is too high, so then there is a cost reduction program. But, it will be difficult to reduce cost at this stage, since 60% of cumulative cost is committed in the architecture stage.   After the above redirections and delays, the project is now behind, so the schedule needs to be “accelerated.” This is so common that one product development book even has a chapter titled, “Through 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. 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 indicated by a prototype.

    Then the typical project starts to consider DFM only as production ramps approach. If DFM was not designed early in the product, it will probably be very difficult to make the product manufacturability through changes at this late a date (Murphy’s law of product development). 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, sometimes taking months to reach the volume production target. 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, or course, emphasizes the importance of measuring time-to-market to the time of full stabilized production, instead of first-customer-ship, which is meaningless as a measure of time-to-market – the factory could build three and ship the one that works!
Does this scenario sound familiar? In fact, most of the attendees queried in the author’s seminars admit that many elements in this sequence are quite familiar, many painfully so.

    In the Advanced Model, all the relevant specialties are present and active early. If each team member has a versatile background and can represent multiple specialties, 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. In addition to the full-time core team are vendor-partners, consultants, and part-time specialists for specific tasks such as various 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: (a) many tasks may be completed; (b) the off-the-shelf parts selected avoid the associated design efforts; (c) vendor-parners help design parts or actually design parts entirely; and (d) 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 engineering resources (the areas under either curve) is half compared to the traditional model.
 

Scheduling for Thorough Up-Front Work

    Significant reductions in the real time-to-market (time to stable production)  is accomplished by thorough, early optimization of the conceptual/architecture phase as shown by Figure 3-1 in Dr. Anderson's DFM book:

 The projected 50% savings in the real time-to-market is due to early concept/architecture optimization minimizing the need for revisions and iterations and making the manufacturing ramp-up several times faster. Note that the architectural phase, labeled “conceptual design,” went from 3% in the old model to 33% (of the total development time) in the new model, an order of magnitude increase! More thorough up-front work decreases the post-design activities (the revisions, iterations, and ramp-up) from almost three-fourths to less than a half of the product development cycle. It is more efficient to incorporate a balance of design considerations early than to implement them later with changes, revisions and iterations.

Figure 3-1 emphasizes one of the most important principles to reduce the real time-to-market: thorough up front work.

Thorough up-front work includes developing and following design strategies, investigate and develop action plans based on lessons learned, raise and resolve issues early, formulate the off-the-shelf part strategy early before arbitrary decisions preclude their use, and develop strategies for concurrently engineered processing, vendor/partnerships, designed in quality, mistakeproofing (Poka-Yoke), test, supply chain management, customizations, configurations, product variety, and derivatives while developing strategies to do-it-right-the-first-time.

The 2006 book, “The Toyota Product Development System,” emphasized the important of thorough up-front work at the company that some say is four times more efficient at product development.  Note that Dr. Anderson's DFM & Concurrent Engineering closely parallels the Toyota Product Development System.

“The ability to influence the success of a product development program is never greater than at the start of a project. The further into the process, the greater the constraints on decision making. As the program progresses, the design space fills, investments are made, and changing course becomes increasingly more expensive, time consuming, and detrimental to product integrity.”

“Empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures.”

  Assuring Enough Resources

1. Teams must insist on, and management must support, a higher proportion of up-front work as shown on the bottom time-lines on both the above graphs.

2.  There must be enough people resources available and not drained away by:

• Poor product portfolio planning that dilutes resources over too many products that put all projects at risk, as shown by the compelling case study presented in the article on Product Portfolio Planning
   
• Too many existing products that drain product development resources, which is also covered in this portfolio case study which should have been eliminated by Product Line Rationalization.
   
• Poor prioritization of projects, not focused on the highest-return projects, which is also covered in the  portfolio case study
   
• Wasting design resources trying to design custom parts in isolation and wasting procurement resources managing bidding wars, instead of pre-selecting vendor-partners who will help design their parts, which will result in a net savings of design cost and development time.
   
• Wasting resources on post-design firefighting and change orders, as shown in the right of the top timelines in both graphs above.
   
• Wasting resources trying to do cost reduction after design when too much is cast in concrete.  See the article at www.HalfCostProducts.com called How Not to Lower Cost.

Case study # 1: Effect of   Demonstrations  too early 

One product development "road map" advises that for technologies that are not ready for market should be "demonstrated very quickly at scale in multiple configurations and in various regional contexts." And acceleration also "requires a large increase in investment in demonstration projects.

THe solution from the author's 600 page book on Design for Manufacturability:

Section 3.2 (Importance of Thorough up-front Work) says: -and this is a full ver-batim quote:

"Unfortunately, once the breadboard "works" and is demonstrated to

management or customers—you guessed it—there is a strong temptation

to "draw it up and get it into production. The unfortunate result is the company ends up mass producing breadboards forever! Basing production designs on breadboard architecture misses the biggest opportunities to make significant reductions in cost and development time." [end quote]

The book goes on to dite Figures 1-1,  2-1, and 3-1 which both prove that 60% of cost is determined by the  cpmvr[y / architechure  phase and an order magitude more erroft there cuts the cime-to-stable-production in half!

If the latter makes more sense, than  the former - or if your work   is very important, challenging, or  timely - then read the 52 articles on this site  or the all editions or the DFM book or  call Dr. Anderson in for consulting  or  seminars.

True innovation must start with Manufacturable Research  steps  
with  the entire team practicing Concurrent Engineering,
 Scalability  , and DFM methodologies from  the beginning.

All of these principles on DFM can be included in
your customized class and workshop on DFM or
the Most Effective Product Development class 

It is Time to  Learn New Ways* to Develop Products (below)

and Stop doing what gets in the Way!

* The 590 page 2020 DFM book has 814 topic section

1. David M. Anderson, Design for Manufacturability & Concurrent Engineering; How to Design for Low Cost, Design in High Quality, Design for Lean Manufacture, and Design Quickly for Fast Production (2010, 432 pages; CIM Press 805-924-0200; www.design4manufacturability.com/books.htm).  Click here for the DFM book description

Dr. David M. Anderson, P.E., CMC
Management Consultant
www.design4manufacturability.com
phone: 1-805-924-0100
fax: 1-805-924-0200

e-mail: anderson@build-to-order-consulting.com
 

[Home]    [DFM consulting]   [DFM seminars]  [DFM webinar]   [DFM Implementation]  [DFM books]

[Half Cost article]   [Standardization article]   [Mass Customization article]   [BTO article]   [Rationalization article]

Copyright © 2020 by David M. Anderson