This paper was presented originally at the ASI Total Product Development Seminar in November 1998. It is reprinted here with minor updating. A note to managers reading this article is appended.
Injecting Creative Thinking Into Product Flow
(formerly) Ford Research Laboratory
(presently) President Ntelleck, LLC
Grosse Ile, Michigan
Structured inventive thinking (SIT)*, a new methodology for problem solving and inventing, has grown from an instructional experiment to a full-time corporate process. Although SIT is quite different from the Russian methodology called TRIZ (pronounced “trees”), it has its roots in TRIZ. SIT originated in Israel in the late 1980’s were it evolved from TRIZ into a compact, non-database oriented system of algorithms and heuristics.
In 1995, SIT was introduced in the Ford Electronics Division as a three-day course open to all corporate technologists. Shortly after this initiation, it was moved to the Ford Research Laboratory where classes have been offered monthly in Dearborn, Michigan and once per year at engineering facilities overseas. Since three days of instruction does not make one a practitioner, weekly SIT User Group meetings are offered to graduates where they address corporate problems that they bring in.
Injecting Creative Thinking Into Product Flow
Ford Research Laboratory
From product concept to product delivery is a straightforward, well-defined path.
Time of travel from one end of the path to the other is also well defined – so well defined, it is chiseled into concrete business plans.
Those two sentences – corporate recipe for apple pie – suffer for lack of reality. Potholes, land mines, detours, dead ends, and a limit of twenty-four hours in a day beset both path and timing for product development. The army of corporate technologists that wage the Job-1 campaign struggle have daily need to solve problems, and may sometimes wish for a miraculous invention to materialize and save their day.
Figure 1. The path from product concept to product delivery, although straight forward and well defined, has many opportunities for set backs, detours, and restarts.
The concept-to-product process is a daunting task that can consume most existing resources and leave little time for innovative thinking and creative problem solving in the day-to-day struggle to stay on schedule. A partial answer to this situation is the strategic application of Structured Inventive Thinking* (SIT), a new methodology for solving engineering design-type problems.
An experiment at the Ford Motor Company Research Laboratory in Dearborn, Michigan, has been in place for the past year to determine whether a team of SIT trained experts can inject innovation where product technologists need assistance. Charged to apply SIT to corporate problems world wide, the team addresses warranty, product improvement, manufacturing, and other problems conceptually. The team’s deliverables to its customers are concepts: they fall in the first block of the concept-to-product path shown in Fig. (1). Fresh, innovative concepts are very often the stymie delaying progress on critical as well as mundane day-to-day engineering problem situations.
The purpose of the FRL SIT-Team is to take a real-world problem, conceptualize it, analyze it, and find multiple conceptual solutions quickly. With the customer’s assistance, these concepts are filtered to select those most suitable for evaluation. The customer then evaluates them, and does all subsequent engineering. Versatility, speed, fresh eyes, cross-function agility, multiple alternatives, and innovation characterize the team and its products.
Typically, three to four, two-hour team meetings with the customer are required to define a problem, educate the team, apply the SIT process, and produce results. Customer participation continues through the process including drafting the final report for the customer’s management (an additional two hour effort, plus six hours to write the final report). Along with the final report, the customer is given an evaluation sheet for critiquing each solution concept and reporting back to the team on which ones will be acted upon, which ones book-shelved, and which ones dropped.
Determination of SIT-Team bottom-line value is an interesting challenge. Its satisfied customers, reputation, and number of patent applications generated attest, in part, its effectiveness; but defining a useful metric of its value is more difficult. Dr. W. F. Powers, Vice President of Research Laboratory, proposed an interesting metric – "save the company one hundred million dollars per year". Suddenly, stretch goals became stress goals! Obviously, this is an experiment and no one knows yet what are realistically achievable goals. So, there was no reason to question the proposed metric.
Note that example solutions are not taken as a measure of the effectiveness of SIT and, therefore, they are not used to measure the value of the SIT team. They do not measure the value of SIT because solutions to problems are unique to the problem not the methodology used to find the solutions. Example solutions are not used to measure the value of the team because the more important concern is deemed to be whether the SIT-team solution concepts actually make it all the way to a product.
In order to bring value into focus, the team has begun collecting cost-to-customer information on each problem it is asked to examine. Of interest is how much the problem is costing the customer (i.e., the company) while it remains unresolved. This number is called the "carrot" that is being used to engage the SIT team. But actual value to the company may be something quite different and may not be known for some time. Consider the process a concept must go through before its actual value can be accounted:
Discussion with experienced product engineers reveals reasonable expectations for concepts at a given product development level in the above process succeeding to the next level. It is a narrowing function as illustrated in Fig. (2).
In evaluating the SIT team, it is not so important how many ideas are generated for a given project, but how many, if any, succeed to a final product. Thus, the probability of project succeeding, rather than concept succeeding, is used as the ordinate in Fig. (2)
Figure 2. Probability of any solution concepts for a given project succeeding to a final product depending on the (product development) level of their existence (shown as rectangles) is illustrated versus the number of concepts remaining in a stage. The width of each stage indicates the fraction of concepts that arrive from the previous stage.
When the abscissa in Fig. (2) is changed from number of concepts to "carrot" dollars, a display of potential value of SIT-Team projects is derived. An example is shown in Fig. (3).
Figure 3. SIT-Team value as measured by the status of two example projects.
Project 23, in Fig. (3), involves a "field-fix" for a warranty problem. It is now in the design verification stage and progressing steadily toward final verification. Project 22 involves a product improvement that arose out of solving a warranty problem. It has achieved product adoption but is a temporary solution. A still better design is in design verification and will replace P22 at a future date. Consequently, the final dollar value of P22 will not be known until its replacement is in place.
Of course, not all SIT-Team projects have been as successful as these two examples. While the carrot-dollar values of other projects are very attractive their progress toward adoption has been slow. This slower pace is more typical of the concept-to-product process. Couple this with the newness of the SIT-Team experiment and present results appear the more attractive. The team’s weekly project log tracts each project as well as the net carrot-dollar value of the team’s portfolio. The team is proud to note that it is on target for its "stress" goal.
As shown above, carrot-dollars can be used to justify the engagement of SIT-Team resources, and actual dollar value may be eventually assigned to concepts that succeed to product adoption. But this raises a question of how much of the final dollar value of a SIT-Team concept should or could be credited to the SIT Team. The SIT-Team’s deliverable is a concept, a bare concept yet to be evaluated, engineered, and tested. Considerable resources, including multiple technologists, must be involved before a concept can reach a product. Who gets the final credit? Until this whole experiment and its results are understood better, an interim procedure has been put in place to credit the SIT Team as being participants in the larger engineering team that carries the concept to completion. Therefore, credit is shared as appropriate for the larger team.
Communicating to corporate technologists this new resource, support for rapid development of multiple solution concepts to engineering problems, has been slow as has been their motivation to call upon the SIT Team. Potential reasons for this have been postulated including, the not-invented-here syndrome, admission of defeat (especially for problems that have been around a long time with no progress toward their resolution), and the culture shock associated with the new idea of what constitutes a deliverable – a bare, non-engineered solution concept. More realistic reasons include lack of time, low priority assigned to problem resolution, and lack of realization of the importance of a solution concept in starting the engineering process.
Communication of the SIT-Team resource is being done through three routes. Monthly, three-day classes in SIT are taught in the Research Laboratory, and once a year at overseas engineering facilities. SIT graduates are an active source of SIT-Team customers. In addition to SIT classes, weekly SIT User Group meetings are held where corporate problems are brought for analysis and further development of SIT practitioner skills. Sometimes these problems are moved to the SIT Team. The third route is through personal contacts made by SIT-Team members who track and identify problems surfacing around the company.
It was recognized early that SIT was an unusually effective methodology for injecting innovation into problem solving. This led to initiation of an in-house training program. It gradually is becoming evident that dedicated teams can employ it to inject innovation into product flow.
(*) Further reading on structured inventive thinking can be found on the web at http://www.u-sit.net
SIT and USIT:
SIT, as reported here, was derived from the Israeli SIT method and introduced into Ford Motor Company in 1995. While at Ford I wrote the first textbook on the methodology and titled it “Unified Structured Inventive Thinking – How to Invent” (USIT). With Ford’s permission the textbook and USIT training courses are marketed outside of Ford Motor Company. USIT differs from SIT (Ford version and the current Israeli version called ASIT) in that USIT has a theoretical basis incorporated into it in which all components and processes are based logically on objects, attributes, and functions. New techniques in USIT include object-minimization to a single point of contact, object-attribute-function statements, plausible-root-causes tool, and transduction as a solution technique. Free USIT e-books and a newsletter are available at www.u-sit.net. Since my retirement from Ford Motor Company in 2000, SIT has been incorporated in the official corporate training program catalog and is being taught by my former colleague, Dr. Craig Stephan.
To Corporate Managers:
If in reading this you are disappointed for lack of specific examples of solved problems, consider the following two points. 1) It has been my experience that companies typically do not want their specific problems discussed outside of their corporate boundaries. Problems brought to on-sight USIT training courses are often very interesting but too proprietary for publication. 2) In addition, there is a very important reason for not using examples in presentations to management (this article) – they can be misinterpreted and generally misleading. Example problems demonstrate solutions to problems but do not evaluate the method used to find the solution. Solution concepts are not unique to a problem-solving methodology. They are unique to the problem they solve and can be found by multiple methodologies. Understand this difference and you will not be misled.