By Darrell Mann
There has been considerable discussion in recent years concerning the relative importance of physical and technical contradictions. The clear implication from ARIZ-based processes and from the majority of former-Soviet Bloc authors is that the physical contradiction is more important than the technical contradiction. More recent evidence presented at a 2002 conference suggests that, in terms of numbers of ideas generated, there is no significant difference between the types. (1) The presenters also noted that when both physical and technical contradictions were considered the total number of useful ideas generated was considerably higher. In retrospect this latter finding should not be a surprise; making a choice between tackling a problem as a physical contradiction or a technical contradiction is in itself another contradiction. When in any either/or discussion, the best answer is very likely that a) we are asking the wrong question and b) that to adopt a both/and approach is far preferable to an either/or alternative.
The aim of this article is to dig deeper into the physical vs. technical contradiction debate in two parts. This article will focus on individual contradictions. We will start by revisiting a contradiction scheme first introduced in the business version of Hands On Systematic Innovation. (2)
The scheme shown in Figure 1 is based on the ‘Evaporating Cloud' idea conceived within the Theory of Constraints methodology. (3) The figure differs only insofar as there is an additional line connecting the two conflict parameters 1 and 2. This modified Evaporating Cloud scheme has proven to be an excellent way of converting between technical and physical contradictions. On the right hand side of the picture are two ovals ‘Parameter A' and ‘Parameter –A.' These two parameters, as defined in the Evaporating Cloud model, represent the physical contradiction. The ‘Conflict Parameter 1' and ‘Conflict Parameter 2' ovals represent the technical contradiction. Although these two items are also in the original Evaporating Cloud model, they are not identified as being in conflict with each other. This connection is more explicit in Figure 1 with the connection of the two ovals – this is the technical contradiction, since we are defining the problem with both of the defined parameters. On the left hand side of the figure is the ‘successful outcome' – this is the aspect of the system that both of the conflict parameters are required to support.
The ‘because' and ‘requires' arrows at the top and bottom of the scheme are the code words that will allow for the conversion from one type of contradiction to another. It is worth thinking about what the Theory of Constraints has to say about solving the problem described by their version of the model. Solving the problem (‘evaporating the cloud') requires one of the links between adjacent ovals to be ‘broken' or ‘evaporated.' TRIZ tells us that whatever the technical contradiction we defined, someone, somewhere has already solved it, thus there is a link between the two conflict parameters compared to the Evaporating Cloud model. ‘Solving the contradiction' in these terms means challenging (‘breaking' or ‘evaporating') at least one of the six (blue line) links in Figure 1.
There is considerable interest these days in unmanned air vehicles (UAVs). These remote-controlled aircraft – like the small RQ-7 machine shown in Figure 2 – are useful for reconnaissance over dangerous and/or difficult to access areas. They are basically controlled from a base-station and are required to transmit data – usually pictures – back to this base-station from the area over which they are directed to fly.
The RQ-7 UAV is propeller-driven via a small petrol-driven piston engine. If we ask ‘what might we like to improve about this machine?' one answer may be noise. Remote-controlled aircraft can be very loud indeed, and this can be a problem if the goal is for the aircraft to remain undetected. We have identified something that we would like to improve. The operators of the RQ-7 (and similar aircraft) are aware of the noise problem. The solution generally used to reduce the likelihood of the machine being detected is to fly at a higher altitude. Unfortunately, this presents a considerable trade-off because the higher the UAV flies the more difficult it is to get a good image of the area being photographed.
The general scheme presented in Figure 1 can be applied specifically to this situation as shown in Figure 3.
‘Low noise' requires ‘high altitude' as noted in the top link. Expressed differently, the link means ‘we require high altitude because we require low noise. Te other links can be described in similar terms; a ‘successful mission' requires ‘low noise,' or ‘we want low altitude because low altitude gives good image clarity.'
From a traditional TRIZ perspective, the two vertical links define our technical and physical contradictions. The physical contradiction in this case is that we want to fly at high altitude and low altitude; the technical contradiction is between noise and image clarity.
There is no suggestion that either the physical contradiction or the technical contradiction is any more important than the other. Indeed, the contradiction map says that the two contradictions operate at the same level and are directly translatable – equivalent to one another.
We take this a step further by relating back to the Evaporating Cloud statement that ‘solving the problem' requires us to break one of the links. This model shows that we have six opportunities to do that job. The ‘noise-vs.-image' technical contradiction and the ‘high-vs.-low' physical contradiction are two of the six. The other four can be described by examining the other four links. Figure 4 explains all six of the contradiction solving opportunities.
The figure goes a step further in that it has interpreted the specific conflict pairs and interpreted them onto a 2003 version of the Contradiction Matrix. (4) In the case of the ‘high-vs.-low' altitude physical contradiction, we can also relate the traditional ‘separate in space,' ‘separate in time' and ‘separate on condition' strategies to the same 40 Inventive Principles as in the Contradiction Matrix. The fact that we can make such a conversion shows that there is no real hierarchical difference between technical and physical contradictions. In Figure 4, the new Matrix+ software tool generated the Inventive Principle suggestions. (5) For the physical contradiction we need to consider separations in ‘space,' ‘time' and ‘on condition;' the software lists all of the Inventive Principles.
The list of recommendations for each of the six conflicts looked up on the Matrix is different from the Inventive Principles. This is because each of the six links in the model represents a distinctly different problem. There is a tendency to try and merge these different problems into one in order to get a combined list of prioritized Principles. This can work, but in general – particularly when using Matrix 2003 – it is far more effective to focus the Principles suggested by the method on the specific conflict pair that was used to generate those Principles. Trying to solve a ‘noise-vs.-altitude' problem is not the same as trying to solve a ‘mission-success-(‘productivity,' ‘amount of information,' etc. in the model) vs.-image' clarity conflict.
Figure 4 also serves to understand why the 2002 presenters observed that users were able to generate more and better solutions by looking at both physical and contradictions than if they had just looked at one of the two. (1) Figure 4 demonstrates that there is not just a choice between technical and physical contradiction solution strategies, but that for any conflict situation there are six possible solution generation opportunity points.
We will examine how some of the inevitable conflicts surrounding the UAV problem (and indeed any other situation) are coupled and can be managed in a way that allows us to identify, and evaporate, the right cloud.
Darrell Mann is an engineer by background, having spent 15 years working at Rolls-Royce in various long-term R&D related positions, and ultimately becoming responsible for the company's long-term future engine strategy. He left the company in 1996 to help set up a high technology company before entering a program of systematic innovation and creativity research at the University of Bath. He first started using TRIZ in 1992, and by the time he left Rolls-Royce had generated over a dozen patents and patent applications. In 1998 he started teaching TRIZ and related methods to both technical and business audiences, and to date has given courses to more than 3,000 delegates across a broad spectrum of industries and disciplines. He continues to actively use, teach and research systematic innovation techniques and is author of the best selling book series Hands-On Systematic Innovation. Contact Darrell Mann at darrell.mann (at) systematic-innovation.com or visit http://www.systematic-innovation.com.