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”?

Keys to Effective Product Development

We can define effective product development as achieving the shortest possible development cycle time at the lowest possible cost consistent with the desired product quality. Achieving effective product development requires effective leadership, good teamwork and the use of effective methods and tools. Since effective leadership promotes good teamwork it is fair to say that effective leadership, methods and tools are necessary. These are pretty general statements so it helps to dig one level deeper and look at some requirements for effective product development from a different perspective. I believe some of the most important elements of effective product development are:

1. Effective communications between managers, systems engineers, design engineers, suppliers and personnel responsible for production as indicated in Figure 1-1. If customers are paying for all or a portion of the development cost then they must be included in this diagram also.

Figure 1-1 Communications must be maintained between all personnel involved in product development.

2. Never having to redo something that was done correctly on a previous development program.

3. Using modern methods that have proven effective in minimizing information latency. (Information latency is the time between when information is available and when it is communicated to those that need the information to do their work.)

4. Working as a team and using good teamwork practices.

5. Developing schedules and assigning resources that accommodate working as a team and the uncertainties of future design decisions.

6. Using tools and methods that facilitate preventing problems rather than finding and fixing problems.

7. Maintaining the discipline of always conducting peer reviews of engineering work and providing time for peer reviews in project schedules.

8. Giving task leaders and engineers the authority to seek input from anyone they believe they need help from in order to achieve their best work.

9. Technical, financial and market value statements must be considered at each stage of the development.

Elements 1, 7 and 8 are tied to leadership and can be studied in depth in my book “The Manager’s Guide for Effective Leadership”.  Element 9 is a statement of the basic discipline teams must follow to keep product development on track.
 The other five elements relate to methods and tools and methods and tools can contribute to element 1. I think these first six important elements are only achievable if systems engineering methods and tools are used in product development in addition to good design practices and tools. Subsequent posts describe some of the systems engineering methods and tools that contribute to effective product development.  Enterprises doing work for the U. S. Department of Defense and NASA typically use systems engineering methods but this practice is not always followed in other enterprises or government agencies. 

If in your experience you believe there are other important elements please share them in your comments.

Objectives of Part I, Fundamentals of Systems Engineering

Part I is intended to provide three understandings:

1.      The Key systems engineering activities that are critical to the success of product development

2.      How and why product development has evolved

3.      The roles and responsibilities of systems engineers and other team members in modern product development

However, before we begin to address these three understandings there is some introductory material that needs to be explained. In addition to the three understanding listed, Part I seeks to explain important processes and tools available to engineers for reducing product development time, shows some practical examples of the processes and tools and provide the reader exercises to practice applying these processes and tools.

Understanding how and why product development has evolved over the past century is helpful in understanding modern methods. It also aids in encouraging the use of modern methods. Understanding the roles and responsibilities of systems engineers and other team members helps promote working as part of a team and hopefully encourages system engineers and their managers to involve design engineers, suppliers and manufacturing people earlier in product development. Understanding key system engineering activities helps encourage focusing on the product under development, not the development process and helps understand the implications of the complexity of modern systems and how to deal with this complexity.

The objective of product development is to achieve the shortest practical time from concept to production, which we can call development cycle time, at the lowest cost consistent with the required product quality. Numerous books and papers have discussed the importance of being first to market, or if not being first, getting to market with cost or feature advantages. Unfortunately, product development managers too often attempt to shorten the development cycle by limiting the systems engineering effort or terminating the systems engineering too early. Study after study has shown that cutting corners in systems engineering to save perhaps 5% in development cost or time results in problems in the later stages of the development cycle, like system test and in initial production, that increase development costs and time by 50 to 100%. The reason this happens is also revealed in such studies of costs over the development cycle. The systems engineering phase of product development typically costs about 10% of the total product development. However, it is found that often 80 to 90 % of the system costs are determined by decisions made while spending this first 10% of the development cost. There are two important consequences of this finding.

One is that it is possible to explore many design approaches during the systems engineering phase at very low cost. Only a portion of the systems engineering costs are spent exploring design approaches; the rest is spent on requirements analysis, documentation and communication. Thus it's possible to explore perhaps twice as many system design approaches for an increase in total development cost of only about 2%.  Since doubling the number of design approaches explored significantly increases the likelihood that a higher quality or lower cost design approach is found it is well worth the extra expense.

The second important consequence is that systems engineering occurs at the beginning of the development cycle and no product development manager wants to deviate from a planned budget in the earliest stage of a project. It takes exceptional courage for a project manager to overrun the planned budget during the systems engineering phase no matter how well the manager understands the likely consequences. It is just human nature to hope that past lessons learned won’t apply to the current project. Thus managers are tempted to cut corners during systems engineering rather than conduct a thorough job even though doing a thorough job is highly likely to save costs in the long run.

There is a way out of the manager's dilemma and the way out is to use modern systems engineering methods that dramatically shorten the time and cost of the systems engineering phase of product development and improve the quality of the systems engineering work at the same time. I know that this sounds too good to be true but it has been proven to work.

 If the modern methods are so effective why isn’t everyone using them? Good question. In my experience one reason is that organizations are reluctant to try new methods and another is that these new methods can be costly to implement if not done properly. I hope to show that there is a very cost effective way to implement these new methods. That is the subject for Part II of this work. But before we begin to explore new methods it’s important to understand how to best use traditional methods because using best practices with traditional methods carries over to helping achieve the best use of more modern methods.