Review of Fundamental Principles for Product Development

Examination of the “lessons learned” from over 50 years of evolving product design methods suggest that there are some basic principles that should be considered when examining new methods or tools for product development. Some are evident in the examples given in the previous posts and others derive from the experience of successful systems engineering teams. I suggest we can summarize these into 12 principles that underlie modern product development methods:

1. The best model for a simple product development is a “Craftsman” model, i.e. a Chief Engineer with total project visibility and responsibility. 
2. Complex products should be decomposed into simpler pieces so that the craftsman model can be applied to each piece.
3. All activities in a product’s development must become one integrated effort.  (Otherwise, #2 cannot be implemented successfully.)
4. Trade-off within single disciplines must be subordinated to trade-offs across disciplines. (Necessary to achieve a “balanced” design.)
5. Authority must be shared among members of a collaborative, multi-disciplined team.
6. Product complexity will continue to increase, leading to the need for more engineering specialization.  (And the need for better systems engineering tools)
7. The complexity of system engineering tools should be matched to the complexity of the product
8. Continuous Process Improvement of product design methods is essential to compete successfully in a global market.
9. A competitive advantage is realized from technology and tools that provide all team members complete visibility of evolving designs, support in identifying and resolving conflicts, and the ability to equally influence decisions.
10. Modern methods are essential to shorting the time to prevent design errors; rather than to find and fix design errors, and thereby facilitate achieving minimum product development cost and schedule.
11. Functional managers must collaborate, share responsibility in measuring team performance, and foster unity of purpose within and among teams.
12. Product development schedules must account for resource contentions within the team and among teams.

The reason the Craftsman model is the best for simple products or simple portions of complex products is that all the information necessary to guide the design is available in the mind of the experienced leader or chief engineer. This is best because it reduces information latency to an absolute minimum. If information latency is minimized then the conditions for minimizing cost and schedule are in place. This means that cost and schedule will be minimized assuming the other principles are also fulfilled. (The principles could be summarized in a shorter list if the principle of minimizing information latency is invoked. However, decomposing this fundamental principle into subordinate principles makes it easier for systems engineers and product development managers to see how the principle should be implemented on their projects.)

The second principle derives from the first and tells us part of how a product development team should be organized to minimize information latency. It says to decompose the product into pieces (subsystems, assemblies, etc.) to the point that a single lead engineer can be knowledgeable enough to guide the development of the piece. This lead engineer must be supported by the needed specialty engineers and must work with other team leaders to achieve a balanced design but the individual should be capable of being responsible for all design decisions on the piece assigned. How all these small teams are organized into an overall integrated team is the subject of principle 3 and the core organizational issue of IPD.

Principle 4 says that one of the responsibilities of systems engineering is to manage the tradeoffs between different disciplines (and teams) so that a balanced design is achieved. For example, compromises are often needed between electrical design and thermal design or between mechanical design and optical design. If the systems engineers allow one discipline to dominate then that discipline will make their portion of the design optimum at the expense of other disciplines; resulting in an unbalanced design which is usually not robust to the variability of use. Principle 5 is a necessary condition for successfully implementing principle 4.

Principles 6 should be self-evident and principles 7 and 8 follow from 6. Principle 9 is derived from examining the question of how we achieve the benefits of the craftsman model for the development of modern complex products with many engineering specialties. For a number of years I used this principle in training systems engineers and had to admit that I did not know how to achieve the goals listed in this principle. New methods emerged in the late 1990s that now enable teams to achieve the goals of principle 9 and these new methods are addressed in Part II of this training material.

Principle 10 says that teams must use methods like peer reviews, progressive freeze, quality function deployment (QFD) and risk management to achieve minimum cost and schedule. This list is meant to be illustrative and is definitely not a complete list of modern methods and communication tools needed for effective systems engineering and product development. None of these methods is difficult but teams must exhibit good discipline to maintain effective use of these tools and inexperienced managers sometimes fail to maintain the necessary discipline.

Principles 11 and 12 are “housekeeping” principles and perhaps could be left off this list but they are added as reminders.

Exercises

Before proceeding to the next series of posts take a few minutes and consider the following questions:

1. Review the product development processes in your organization and rate them against the list of 12 principles stated above on a scale of 1 to 5, with 5 being full satisfaction of the principle. If your organization achieves a score of 50 or above it’s likely that it’s competitive with most of its competitors. If the score is below 50 then there is work to do even before trying to implement the 21^st century methods that will be introduced later.

2. Describe the end to end product development process in simple terms your grandmother could understand (assuming she is not a systems engineer) if she asked “what are the steps in product development”?