Editor | On 03, Jun 2000

First presented at the Altshuller Institute TRIZCON2000, May 1, 2000

By Dr. Larry Zeidner and Dr. Ralph Wood

Executive Summary:

The Collaborative Innovation (CI) process has been developed at United Technologies Research Center (UTRC) as an integrated collection of best-practice design methods (including TRIZ), enhanced and simplified to support Integrated Product Development (IPD) teams during conceptual design. Over the past 3 years, CI has been applied to a wide range of UTC innovation efforts, from cost-reduction of mature products to clean-sheet design of new types of products & processes. The CI process enables an IPD team to: a) focus their innovation efforts on opportunities that have the greatest potential of adding stakeholder value, b) use stakeholder value to guide concept evaluation and selection, and c) create a development plan that will reduce risk as quickly as possible.

Introduction:

CI is focused on conceptual design because it has long been clear that at least 70% of the cost, reliability, performance, safety, etc. of products are set during conceptual design. Conceptual design is the highest-leverage opportunity for innovation.

Conceptual design teams routinely struggle with 3 issues:

·Innovation effort can be focused on many different aspects of a product and its related processes. Conceptual design teams need to know where to focus their innovation efforts, strategically, to add the most value. Innovation for innovation’s sake alone is not valuable.

·Unlike detailed design, conceptual design lacks detailed prototypes that can be “test-driven” by representative customers or subjected to instrumented testing. During conceptual design, teams typically consider between 10-100 rough-hewn concepts. It is impractical to either confront representative customers with, or test models of all of these concepts. Instead, the team needs a “value-based gauge” that it can use to evaluate and select concepts based on their potential to add stakeholder value.

·Once concepts have been selected, value can only be added if they are pursued; action is required. A pre-requisite to action is a development plan and a clear business case to proceed. There is risk inherent in product development, so decisions are made under conditions of uncertainty and the result is rework. Time and cost for rework can be substantially reduced by development plans that reduce risk as quickly as possible, so that decisions are made under conditions of greater certainty. Conceptual design teams need methods to create development plans that reduce risk as early as possible in the development cycle.

Detailed design involves optimization and determining precise values of design parameters; conceptual design involves consideration of alternative product and process architectures and technological approaches. While bounding ranges for numerical design parameters may be assumed, specific numerical values are as yet unknown. Consequently, conceptual design teams demand quick, simple methods, that are faster and less complex than detailed analyses and detailed requirements definition. They are unwilling to commit the time and effort required to apply detailed methods, since their information is in such rough form. For this reason, many methods that are best practices during detailed design must be simplified for concept design without losing their kernel of effectiveness.

Integrated Product Development (IPD) core teams are ideally composed of and supported by individuals having radically different backgrounds and areas of expertise. It is this diversity that brings a variety of perspectives to conceptual design and increases the likelihood that multiple design alternatives will be generated and evaluated and that life-cycle issues will be considered systemically, rather than as afterthoughts and engineering changes. But many of these diverse individuals are not experts on all facets of the existing product and its related life-cycle processes. They must be provided with appropriate documentation to enable them to understand and contribute to the conceptual design discussion. Available product and process documents are typically suitable for detailed design, involving considerable implementation detail that obscures the fundamental architecture of the product and related processes. Very often, the detailed design documents do not even address the primary conceptual design issues. Conceptual design teams need product/process architectural documentation, without the distraction of detailed-design issues.

This article introduces the Collaborative Innovation (CI) process and its steps for concept design. Each step is explained along with the methods used.

Collaborative Innovation (CI):

During the past 3 years, CI has been developed and used to support conceptual design teams within UTC’s Business Units, including Pratt & Whitney (jet engines), Otis Elevator (elevator systems), and International Fuel Cells (power-generation systems). These teams’ missions ranged from innovative conceptual redesigns for cost reduction of mature products to radically innovative designs of new types of products.

CI sets the stage for innovation by enabling the members of IPD teams, and those who support them, to rapidly engage and contribute, so that they readily add value through the diversity of their backgrounds and skills. CI accomplishes this by modeling the functional architecture of a product and its associated processes so that this information is accessible to the core team and those who support it.

CI explicitly captures the team’s assumptions and decisions so that others in the organization can consider them and add value by identifying necessary adjustments and/or by embracing them based on clear understanding. This is accomplished openly, during frequent reviews, and privately, as individuals draw their own conclusions by examining explicit team documentation.

CI leads to action by presenting a clear business case for its proposed concepts, along with a logically organized wealth of supporting information so that individual assumptions and decisions can be readily substantiated.

Figure 1: CI Process Steps

The CI Process Steps:

CI consists of the 5 steps shown in Figure 1:

1. Value Modeling: Create a weighted stakeholder-value model. Based on input from stakeholder representatives, translate stakeholder needs into a value-based gauge that can be used to evaluate and select concepts.

2. Innovation Focus: Identify where to focus innovation effort to add the most value for stakeholders.

3. Innovation: Innovate in the focus areas, generating a wide variety of concepts that span the design space, minimizing the risk of being “blind-sided” by competitors’ products and processes.

4. Concept Evaluation & Selection: Evaluate concepts, using the value-based gauge, and select those that can add the most value for stakeholders.

5. Risk-Reduced Development Planning (RRDP): Create a development plan to reduce risk as quickly as possible, reducing cost and time for rework.

Figure 2: Using the “Value-Based Gauge” for Value Modeling

Step 1: Value Modeling

The principle of value modeling is illustrated in Figure 2. If the team had an understanding of the relative value of a set of tangible, measurable characteristics of the product or process, and could take a proposed concept and place a gauge against it to measure its score on each characteristic, they would have a good idea of its value. They could readily determine the value of each of its characteristics and thus its total value.

Figure 3: Stakeholder-Needs Modeling

Value Modeling consists of:

·Stakeholder-Needs Modeling:

Relevant stakeholder^* categories are identified (Figure 3). A short list of the stakeholders’ top-level needs is developed. The best available stakeholder representatives are consulted to determine the importance of each need to each category of stakeholder. The stakeholder representatives also provide input to the IPD team’s decision on the relative importance that each category of stakeholder’s perspective will have on the design. A weighted average of these two types of input represents the combined stakeholder value associated with each need.

·Simplified QFD

Quality-Function Deployment (QFD) [Hauser 88] or “House of Quality” is a well-known best practice to understand the relationship between customer needs and ways of satisfying those needs. Elaborate QFD methods have been applied for a wide range of applications, often involving a sequential multi-tiered “waterfall” approach.

Figure 4: Simplified QFD

Figure 4 shows how Simplified QFD is used within CI. A short list of tangible characteristics of the product or process being designed and of related life-cycle processes is created. Each characteristic is believed to be important toward satisfying stakeholder needs and must be able to be assessed for proposed concepts before they have been implemented. The characteristics should be as independent of one another as possible, to avoid double counting. A weighted average of the stakeholder-need weights and the importance weights for the characteristics results in an overall rating of the importance of each characteristic toward providing value. This set of key characteristics, together with their relative weights, is the “Value-Based Gauge” that is later used to evaluate and select concepts.

The primary benefits of Simplified QFD are:

·Its use of only one QFD table: enhanced QFD methods use many cascaded tables, which consume substantial time and therefore limit their usefulness upfront in conceptual design.

·Its concurrency: both product and process characteristics are evaluated simultaneously.

·Its inclusion of “technical certainty” as a standard characteristic to assess the sensitivity of stakeholders to new technology that is not yet “tried and true” in this specific application.

·It combines requirements of all relevant stakeholders, rather than only the Voice of the Customer.

·It identifies contradictions that can be resolved using the TRIZ principles [Altshuller 84] .

Step 2: Innovation Focus

History has shown the disadvantages of focusing innovation where it is technically easiest or where it is most “interesting” or technically challenging. Products and processes that have resulted from such misguided innovation have not generally been successful unless they also happened to add sufficient value.

Focusing innovation based on the actions of market leaders is disadvantageous because only the effect of their design efforts is visible, e.g., the results of their intellectual property (IP) strategy and their first preliminary product offerings. The IP strategy and product and process knowledge that produced these artifacts is not only hidden, but typically one design-cycle old. Focusing solely on these artifacts is likely to perpetuate a market-following position.

A healthier strategy is to evaluate the design space, quickly assessing each area to determine

its potential value, its value with current technology in the current marketplace, and the technology hurdles and market factors that must be overcome to yield its potential. This allows a design team to drill down in areas of the design space that present the most valuable innovation opportunities while understanding and managing the risk that competitors might pursue other areas. This strategy limits competitive risk and enables the business to react with agility when new technologies or market changes present opportunities.

Figure 5: Problem-Formulation (PF) Modeling

Innovation Focus consists of:

·Problem-Formulation (PF) Modeling:

Problem-Formulation [Terninko 98] is a well-known TRIZ method. Figure 5 illustrates Problem-Formulation (PF) modeling as it is used within CI.

The problem-formulation model documents the rationale behind the existing (baseline) product or process design. Modeling begins with identification of the few Principal Useful Functions (PUFs). These are the primary reasons for the product or process’s existence. Next the Useful Functions (UFs), required to provide the PUFs, are modeled. (At this point, the problem-formulation model is essentially equivalent to a standard Functional Analysis Structured Technique (FAST) [Creasy 73] model (commonly used in Value Engineering).

Next, the Harmful Functions (HFs) and Principal Harmful Functions (PHFs), caused by these Useful Functions (Ufs), are modeled. While HFs are disadvantageous, they are not typically obvious or directly problematic to the user. PHFs are more serious than HFs and are typically obvious and problematic to the user. Finally, the UFs, used to mitigate the HFs, are modeled.

Figure 6: The structure of an actual Problem-Formulation (PF) Model (textual descriptors omitted)

Figure 6 shows an example of an actual problem formulation model (the descriptors have been omitted to protect proprietary information). Note that there is a band of PUFs at the top, which this system must perform. Below them is a band of UFs, which are the current design’s approach to performing the PUFs. Below them is a horizontal band of HFs and PHFs, which are caused by the current design’s approach to performing the PUFs. Below them is a band of mitigating UFs, which are useful, but which are only there to solve the problems caused by the current design’s approach to performing the PUFs. Finally, at the bottom of the PF diagram there is a band of HFs and PHFs caused by the mitigation. In this case it is system cost and complexity which feeds back to cause other HFs. In other cases HFs result from requirements on weight, volume, noise, vibration or parasitic losses.

Figure 7: Functional Modeling (FM)

·Functional Modeling (FM):

Functional modeling is a well-known method of understanding which system elements perform which useful and harmful functions. It is a common element in TRIZ analysis, although it takes different forms with different authors. Figures 7 illustrates Functional Modeling (FM) as it is used within CI.

The notation for functional modeling involves blue circles representing elements of the system being designed, green circles representing elements of the “outersystem” (i.e., elements outside the system being designed), and yellow circles representing the stakeholders: outersystem elements that are the primary beneficiaries of the system being designed. (Note that for sub-systems, the stakeholders in a functional model are typically other sub-systems, as opposed to the human stakeholders considered in Value Modeling.)

The functions are represented as arrows between elements. Useful functions are shown in blue and harmful functions in red. A function between two elements indicates that the origin element performs the function and consequently changes or limits an attribute of the destination element. This is analogous to the information in OAF tables, in Ford’s USIT methodology [Sickafus 97] , except that USIT acknowledges not only one, but two origin elements causing the function (as does the theory of Triads [Kowalick 98] ). USIT also explicitly models the attributes of the two origin objects that cause the function to occur, as well as the attribute of the destination object.

Figure 8: An actual one-level Functional Model (textual descriptors omitted)

Figure 9: One page of an actual multi-level Functional Model (textual descriptors omitted)

Figures 8 and 9 show pieces of two different actual functional models in different formats (the descriptors have been omitted to protect proprietary information). Figure 8 shows a complete one-level FM. Figure 9 shows one page of a multi-level FM, in which each element is diagrammed at the center of its own page, showing all of the functional interactions it has with other elements. This approach shows the context, within which each element exists, along with its functional interfaces to that environment. This multi-level modeling is performed using a hierarchical, object-oriented network modeling tool that preserves network integrity, so that all views of the model that involve any particular link show it identically, with all of its relevant graphical and textual attribute information.

Figure 10: Value Analysis (VA)

·Value Analysis (VA):

Value analysis is the part of CI’s innovation focus step that actually identifies where to focus to add value. Value engineering defines the Value of a design as its Functionality (its benefits) divided by its Problems and its Costs [Miles 61] . Figure 10 illustrates how Value Analysis is performed in CI. Functionality is plotted against the sum of Problems and Cost. Functionality includes contribution toPUFs, but does NOT include mitigating UFs. An ideal system element (shown in green) would provide excellent functionality with no problems or costs, while a worthless and harmful system element (shown in red) would provide no functionality but cause significant problems at high cost.

The system elements from the Functional Model are graphed based on their functionality, problems and cost. The diagonal lines are lines of constant value. The horizontal line indicates no value, the 22-degree line represents more value, the 39-degree line represents even more value, etc. So on this graph, element A is of extremely low value, while element B is of extremely high value. Note that cost-reduction teams are purely focused on moving the elements to the left on the VA graph (or eliminating them). Radical Product-Innovation Teams (clean-sheet designs and radical derivatives) are concerned primarily with moving the elements upward on the VA graph, adding substantial new functionality to them (in some cases, by satisfying previously unknown stakeholder needs). These teams may also reduce cost if possible.

Figure 11: PF model patterns and associated supported-brainstorming facilitation questions

Step 3: Innovation

As shown in Figure 11, from the Problem-Formulation model, there is a small set of possible patterns of useful and harmful functions, each of which corresponds to a logical question that should be asked to determine if there’s a better possible design. [Terninko 98] These questions are automatically generated from the PF model. The supported brainstorming process is facilitated using these questions in an order based on their height in the PF model (top to bottom) and proceeds down the branches of the PF model that the Value Analysis indicated were the best opportunities to add value. Since the questions are extremely open-ended for the purpose of facilitation, it is possible to generate questions that are one step less open, in that they pursue a particular conceptual line of change. There are many established sources of these conceptual lines of change, including the TRIZ principles [Altshuller 98] , the USIT solution strategies [Sickafus 97] , the Lateral Thinking techniques [De Bono 90] , and “Thinkertoys” [Michalko 91] .

Figure 12: Pugh Concept Selection

Step 4: Concept Evaluation & Selection

As shown in Figure 12, CI uses “Pugh Concept Selection” [Pugh 91] to evaluate concepts and compare them against a common baseline concept. The Value-Based Gauge created as the result of Value Modeling is used as the weighted selection criteria. Pugh Concept Selection evaluates each system-level concept against a common baseline, which is either the current product design, or a surrogate (the same system that was used as the baseline for PF modeling and for Functional Modeling). For each concept, each product or process characteristic is assessed in comparison with the baseline design. The concept either performs better (“+”) with respect to this characteristic than the baseline, the same (“S”), or worse (“-“). As a result, Pugh produces 3 values for each concept:

·how beneficial the concept is, vs. the value of the baseline (the sum of the weights of characteristics scoring “+”),

·how deficient the concept is, vs. the value of the baseline (the sum of the weights of characteristics scoring “-“), and

·the total value of the concept, vs. the value of the baseline (the sum of the weights of characteristics scoring “+” minus the sum of the weights of characteristics scoring “-“).

Note that the total doesn’t tell the whole story. For example, two concepts could have the same total, while one has excellent advantages along with terrible deficiencies, while the other could just have a few modest advantages and deficiencies. All 3 values are presented and the team’s judgement is used to interpret the results.

Since Pugh Concept Selection compares all concepts against a baseline, it minimizes the number of comparisons that must be considered, as compared with methods such as “paired comparisons.” [Kaufman 89] Since CI provides a direct computational chain, linking stakeholder needs weighting, QFD, and Pugh Concept Selection, validating the QFD and the concept evaluations is easy. Scenarios are used to establish extreme points at which they provide selections that agree with the team’s perception. If a scenario doesn’t provide sensible selections, the relevant portions of the evaluations and then the QFD are examined to determine whether the team’s perceptions, the QFD or the evaluations are at fault. This quickly flushes out evaluation inconsistencies. Since the QFD is meant to explicitly capture the understanding of the team, if it yields results with which the team disagrees, then it is immediately clear where better information or clarification is required. Typical scenarios that can be usefully explored to validate the QFD and the concept evaluations are alternate markets, future markets, and “gut-feel” weightings. Once the QFD and the evaluations have been validated in this fashion, the individual stakeholder-need weightings can be validated by considering them individually and in meaningful groupings as the weights on the rows of the QFD.

Pugh Concept Selection also makes it easy to identify which features of different concepts should be combined to yield higher-value hybrid concepts.

Step 5: Risk-Reduced Development Planning (RRDP)

Once one or more concepts have been selected, the conceptual-design team must create a development plan so that the investment decision, to develop the concept, can be weighed against competing alternative investments (based on metrics such as ROI, NPV, expected value). Technology development and product development both involve considerable risk. Risk is defined as the product of uncertainty of failure and the associated severity of failure. Risk is reduced by either reducing uncertainty, by gathering information or conducting tests or analyses, or by reducing the severity of failure, by increasing the expected value of “fallback” or contingency plans.

It is clear that if risk can be reduced earlier within development, then decisions can be made with greater certainty, and consequently less rework will be necessary. Less rework means shorter time to market and reduced development cost. Risk-Reduced Development Planning is a combination of risk-management best practices [Duncan 96] that a team can use to create a development plan that reduces risk as quickly as possible.

A common problem during the development of product systems arises due to insufficient communication between sub-system organizational groups. When fallback plans are planned without sufficient communication, it is common that some of the sub-system fallback plans have unforeseen complications elsewhere in the system and are thus infeasible. A design team can improve the management of risk by planning system-wide fallback plans explicitly, so that their system-wide viability is assured.

A plan that identifies when risk will be reduced can be used to reduce time-to-market in another way. Passport (“stage-gate” or “tollgate”) reviews can be scheduled to occur soon after significant risk reduction steps have occurred, to minimize the delay from the moment that information is gained to the moment that it is used to decide how to proceed. This delay is wasted time and should be minimized.

Risk-Reduced Development Planning consists of:

·Uncertainty Assessment:

The primary uncertainty issues are identified and assessed based on their likelihood of failure. For each uncertainty issue, the likelihood of failure is comprised of four probabilities that are based on assessment of technology-readiness gaps that routinely lead product development programs to failure. For each uncertainty issue, these gaps assess its intellectual difficulty, the definition and stability of its requirements, the ability to measure its success, and the availability and capability of resources for it.

Figure 13: Evaluation of a risk portfolio along with the initial risk-reduction plan.

·Risk analysis:

As shown in Figure 13, an initial development plan is formulated and the resulting risk portfolio is considered, along with the change in that risk portfolio that would result, if the plan were executed.

Risk involves three additional factors: “time criticality” (when the uncertainty is reduced), dependencies between uncertainties, and severity of adopting fallback plans.

Time criticality is a factor affecting uncertainty. It is the mean time, during the span of the relevant portion of the development program, at which the uncertainty is actually reduced. Clearly, if test results show, during the last day of the program, that the fallback plan must be adopted, then there is no choice — time and budget are both exhausted. However, if test results yield the same result during the first days of the program, there are many options — people are creative and there is plenty of time and budget to find viable alternatives. The later uncertainty is reduced, the higher the effective uncertainty and, consequently, the risk of failure. Time criticality is a multiplying factor that rises exponentially in time to penalize the late resolution of uncertainty.

Dependencies between uncertainties can either increase or decrease their effective uncertainty. When some uncertainty issues adopt their fallback plans, others automatically adopt their fallback plans, regardless of how well they were proceeding. For example, if feasibility of design of a new power supply is one uncertainty issue for a system, and feasibility of design of a multiplexing power-distribution system is another, then fallback to the existing power supply would force abandonment of the new power-distribution system, even if it was actually feasible. On the other hand, when some uncertainty issues adopt their fallback plans, other uncertainty issues are much more likely to succeed. For example, feasibility of design of the system’s thermal-management may be assured to succeed once fallback to the existing power supply occurs.

For each uncertainty issue, the severity of adopting its fallback plan is the remaining element of risk. Severity indicates the loss of stakeholder value involved in adopting the fallback plan. This is the only element of value that is involved in risk. It can be assessed using either the weighted stakeholder needs or the value-based gauge.

·Task segregation and re-sequencing:

The overall development plan is considered, and uncertainty-reducing development tasks are segregated from high-certainty “turn-the-crank” tasks. The entire product-development effort is re-sequenced to first complete the uncertainty-reduction tasks and then, once risk has been substantially reduced, to pursue the high-certainty tasks.

Conclusion

While there are some novel adaptations of best practices in the Collaborative Innovation (CI) process, its novelty is largely its integration and simplification of these best practice methods into a streamlined, repeatable process that can be taught, facilitated and used regularly to drive innovation and stimulate rapid business decision-making.

References:

[Altshuller 84] Altshuller, G.S., Creativity as an Exact Science, Gordon & Breach Science Publishing House, 1984.

[Altshuller 98] Altshuller, G., 40 Principles: TRIZ Keys to Technical Innovation, with drawings by Uri Fedoseev, and additional material by Lev Shulyak. Technical Innovation Center, 1998.

[Creasy 73] Creasy, R., Functional Analysis System Technique Manual, Society of American Value Engineers, 1973.

[De Bono 90] De Bono, E.,Lateral Thinking: Creativity Step-By-Step, Harper Collins, 1990.

[Duncan 96] Duncan, W., A Guide to the Project Management Body of Knowledge, Project Management Institute, 1996. (http://www.pmi.org/)

[Hauser 88] Hauser, J. R. and D. Clausing (1988). “The House of Quality,” The Harvard Business Review, May-June, No. 3, pp 63-73.

[Kaufman 89] Kaufman, J., Value Engineering for the Practitioner, North Carolina State Univ, 1989.

[Kowalick 98] Kowalick, James, “Triads: Their Relationship to TRIZ,” TRIZ Journal, June 1998.

[Michalko 91] Michalko, M., Thinkertoys (A Handbook of Business Creativity), Ten Speed Press, 1991.

[Miles 61] Miles, L. D., Techniques of Value Analysis and Engineering, McGraw-Hill, 1961.

[Pugh 91] Pugh, S., Total design : integrated methods for successful product engineering , Addison-Wesley, 1991.

[Sickafus 97] Sickafus, E. Unified Structured Inventive Thinking: How to Invent, Ntelleck, 1997.

[Terninko 98] Terninko, J., Zusman, A., and Zlotin, B., Systematic Innovation : An Introduction to TRIZ (Theory of Inventive Problem Solving), Saint Lucie Press, 1998.

Author Biography:

Dr. Larry Zeidner leads the Advanced Design Methods (ADM) group at United Technologies Research Center (UTRC). His research involves innovation management, value modeling, functional analysis, supported brainstorming, knowledge management, and risk analysis. Before joining UTRC, Larry was a member of the faculty in Boston University’s Manufacturing Engineering Department, where his research and teaching included automatic generation of code to drive NC machines for custom “art to part” manufacturing systems, graphically programmed cooperative asynchronous hardware/software systems, and advanced graphical user interfaces. Larry earned his PhD in Civil Engineering in 1983 and his BSE in Electrical Engineering and Computer Science in 1980, from Princeton University.

Dr. Ralph T. Wood is Director of Enterprise Productivity, UTC Corporate Quality. For 5 years prior to this assignment, he led the Product Development and Manufacturing Department and then the Management of Technology Department at the United Technologies Research Center. From 1990 to 1994 he was the Associate Director of DARPA’s Concurrent Engineering Research Center at West Virginia University and a consultant on product development to industry. Ralph spent the majority of his career at GE, starting at Knolls Atomic Power Laboratory, where he was a lead methods development engineer working on naval nuclear reactors, and ending at GE’s Corporate Research and Development Center, where he conducted R&D programs in energy conversion, two-phase flow, nuclear reactor containment, process modeling, industrial lasers, intelligent processing of materials, and concurrent engineering. Ralph holds ScB, ScM, and PhD degrees in mechanical engineering from Brown University. He is co-author of three US Patents and numerous journal articles.

---

^* Stakeholders are those affected by the product or process design, and whose perspective is considered important (typically due to influence on the purchasing decision). Typical stakeholders include customers (divided into relevant market segments), regulatory agencies, and organizations within the value chain (e.g., new-product design & manufacturing, maintenance, repair & overhaul).