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.

Recommended Study Approaches

The material to be presented in this blog is structured similar to a text book but with some important differences. It can be studied by individuals but it is more effective to study as a team of four to six people. If there are more than six people studying then break up into more teams. The best and most effective study approach is for a team that is just starting a new product development project to study this material together and to use the recommended exercises to develop required documentation for their project. Thus this material becomes an adjunct guide during the systems engineering phase of their work. If only one individual or one team is studying then save the results of the exercises electronically so that these results can be reused on future product developments. If more than one team is studying it helps to do the exercises either on flip charts to facilitate sharing each team’s results or in a facility that enables electronic sharing of exercise results.

If a team isn't at the beginning of a new project the second best study approach is for the team to invent a straw man product and work through the material developing documentation for the straw man product. It is critical that the straw man product be as close as possible to a typical product the organization typically develops. The reason is that the documentation developed during the study of this material is intended to become the first generation of templates that are reusable on future product developments.

If an individual  is studying this material on their own then either the straw man product approach can be used or choose a previous product from the organization's development history for the exercises.

Since these blogs are posted over time it is not effective for a team assigned to a new project to use these blog articles for training because their work should progress much faster than the articles will be posted. The recommended approach is for a manager with training ability or a trainer to study the blogs and use the blogs material to develop a training course that can be taught to a team in three to five days. The individual articles will be grouped into chapters and the chapters will be posted to a site that enables them to be down loaded and assembled into a training manual or a guidebook for self-training. Alternatively a team or teams can study from the blog articles by meeting briefly every few days and discussing the articles posted. In this case using a straw man product for the exercise will be effective.

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.

More on Objectives of This Blog

Systems engineering is an ever evolving engineering discipline. In the late 1990s new methods emerged that enable shorter product development cycles and at the same time improve the quality of systems engineering documentation that is critical to the development of high quality products. Systems engineers and managers of product development have an excellent selection of handbooks and books available from US Government agencies and professional organizations that treat systems engineering fundamentals. Unfortunately the documents I am familiar with have not incorporated the newest methodologies. The intent of this work is to provide a self-training guidebook in these new methodologies so that product development organizations can realize significant reductions in the systems engineering portions of product development and achieve higher quality systems engineering products. The specific objectives of this material are to:

·         Teach modern systems engineering methods that support product development on short schedules and at low development costs

·         Teach methods and tools in formats compatible with standard systems engineering references to enable students to continue to study on their own after finishing this material

·         Provide initial steps toward systems engineering templates for rapid product development

The approach that will be followed is to:

·         First review the fundamentals necessary to understand modern methods

·         Summarize how  engineering methods has evolved and led to modern systems engineering

·         Provide exercises for the students that become initial steps toward templates specific to their work

·         Describe methods and tools in formats compatible with standard references

The material presented here has evolved over a number of years and from a number of sources. The most important sources include:

·         “Best Practices” of engineers on successful projects in the author’s experience

·         The Department of Defense Systems Management College publication “Systems Engineering Fundamentals”

·         IEEE Std 1220 Application and Management of the Systems Engineering Process

·         INCOSE (International Council on Systems Engineering) Systems Engineering Handbook, http://www.incose.org

·         GPR 7120.5A  Systems Engineering (GPR is NASA Goddard Procedural Requirements)

·         An INCOSE Presentation by James Long of the ViTech Corporation

·         The Systematica™ Methodology of Bill Schindel

·         Studies of “Integrated Concurrent Engineering” available on the internet.

The intention of the author is that this material complements “Systems Engineering Fundamentals” and  IEEE 1220 so that students can continue to study using these two sources after completing this material. However, “Systems Engineering Fundamentals” and IEEE 1220 are not a substitute for studying this material because concepts critical to short cycle time and low cost systems engineering are presented here that are not in the two references.  Thus this material plus “Systems Engineering Fundamentals” and IEEE 1220, or this material plus the INCOSE “Systems Engineering Handbook” can be considered a handbook for top level systems engineering.

This material will not:

·         Teach the domain knowledge specific to any particular system

·         Substitute for the years of experience and engineering education that serve as the foundation needed by systems engineers

·         Teach the detailed systems engineering processes covered very well by the complementary books referenced above

A cautionary note on systems engineering nomenclature is necessary for readers. Systems engineering nomenclature is not standardized although there are efforts underway. Therefore I cannot claim to exclusively use standard nomenclature. I will try to use nomenclature consistent with the INCOSE “Systems Engineering Handbook” and DoD’s “Systems Engineering Fundamentals”. I have never found the inconsistency in nomenclature to be a problem but I am sure that some readers will; so I apologize to those readers for the times that I use unfamiliar nomenclature or deviate from my intent to be consistent with the documents cited here.

The material that will be presented is not for systems engineers alone. It should be read by managers responsible for systems engineering including functional engineering managers and product development managers. It does little good to have systems engineers trained in the most modern and efficient methods if their managers do not understand the value of modern methods and do not support the implementation and use of these methods. It is also valuable for other engineers involved in product development to learn these methods because many apply to design engineering as well as systems engineering.

The material is presented in three Parts:

•         Part I – Fundamentals of Systems Engineering

•         Part II- Introduction to Model and Pattern Based Systems Engineering

•         Part III- Alternate Description of Fundamental Systems Engineering Tasks (This is the part that recasts methods and tools in formats compatible with standard references.