Problem Solving - Then Came TRIZ

Marc

Fully vaccinated are you?
Leader
Opinions???

Note the diagrams are off because of proportional font problems in rendering in the bbs software - but the essence is here...

-----snippo-----

Date: Tue, 8 Dec 1998 19:46:29 -0500
From: "Francis S. (Frank) Patrick"
Subject: Re: Problem solving techniques

**** Warning -- Long posting ahead ****

Problems are related to dilemmas, doubts, and decisions. From a "scientific" viewpoint, any problem can be stated in terms of a conflict or conflicts between what are perceived to be necessary conditions of the system that's involved. TRIZ, recently mentioned in this thread, recognizes this in the way with it deals with conflicts between physical or technical aspects between design requirements encountered in the "invention" process. There is also another body of knowledge with a set of tools that are used for problem solving.

The tools that I'm about to discuss are "thinking tools" (known as a group as the Theory of Constraints (TOC) Thinking Processes). They can be used in standalone situations, or together they form a coherent problem-solving and change management system. Their generic purpose is to translate intuition to a format that can be discussed rationally, questioned without offense, and modified to more fully reflect the understanding of the situation. They are used for the construction of common sense solutions to problems as well as to facilitate communication, collaboration, and consensus among those that must be involved in its resolution.


THE CONTEXT

To put any set of tools in context, they must generally support one of three generic objectives that groups are brought together to accomplish. These three objectives are to determine:

WHAT TO CHANGE
(Situation assessment, description of "current reality," and identification of the core problem or conflict and assumptions that sustain it -- diagnosis)

WHAT TO CHANGE TO
(Verbalization of vision/solution and description of strategy to attain the desired state -- prescription, decision making, and solution development)

HOW TO MAKE THE CHANGE HAPPEN
(Development of detailed plans and tactics that will clarify what needs to happen and synchronize the efforts of the group in the implementation of the strategy -- planning, team-building)

Any time a problem is encountered, its solution usually relates to one or more of the three purpose above.

Before I get into the specific tools and how they relate to these three purposes, I should really describe the two overarching "meta-tools" that are at the core of the tools -- SUFFICIENCY LOGIC and NECESSITY LOGIC.

Sufficiency logic consists of "If...,then...,because..." descriptions of why situations exist or why we believe actions will result in particular outcomes. Linkages of sufficiency logic are also frequently expressed as "If..., and if..., and if..., then..." as in the case when it take three preexisting conditions (the "ifs") to result in the outcome (the "then").

Necessity logic often takes the form of "In order to..., we must...," describing requirements or prerequisites associated with desired outcomes. These requirements may not be sufficient in and of themselves to result in the outcome, but their existence is seen as necessary for it. Linkages based on necessity logic can often be augmented with a "because..." factor as well, which is a very powerful mechanism for surfacing beliefs or assumptions that underlie why we feel we must have A in order to have B.

The Thinking Processes, based on these two logical constructs, get their power from the fact that the human mind seems to be practically "hard-wired" with an innate understanding of when the "if-thens" or the "in-order-to, we-musts" make sense or not, lending themselves to an ease of communication, scrutiny, and revision. They also benefit from graphical formats and presentation, so the mind can readily take in not only the words of the various entities, but also the spatial relationships implied by connecting arrows.

The tools serve to communicate or verbalize the intuition of the participants in a way that lends itself to collaboration and dialogue and results in a description of the "common sense" of the participants.


THE TOOLS

Tool 1 -- The Evaporating Cloud

The Evaporating Cloud is a construct of necessity logic that takes the
form:
Code:
               B) Requirement <-----  D) Prerequisite
              /                              ^
             /                               |
            v                                |
A) Objective                                 |/| -- conflict
            ^                                  |
             \                                 |
              \                                v
               C) Requirement <-----  D') Prerequisite
and is read:

In order to have objective A, we must have requirement B...
In order to have requirement B, we must have prerequisite D...
In order to have objective A, we must have requirement C...
In order to have requirement C, we must have prerequisite D'...
But prerequisites D and D' are in conflict...

One of the tenets of the Theory of Constraints, reflecting its roots in the application of the techniques associated with scientific method to those "soft sciences" like management and behavior, is that in any system that is brought together for a purpose, there is no such thing as real conflict, but only unexamined assumptions. The cloud allows a clear statement of the perceived dilemma and provides a route for the surfacing and scrutiny of those assumptions.

I've written about the Evaporating Cloud a number of times in the past in this discussion list, but I'll repeat again that under every arrow (including the conflict arrow between D and D') lie assumptions. Brainstorming those assumptions is a matter of reading the "in order to, we must" statements, and then adding the word "because..." to it, soliciting reasons why A requires B or C requires D', or why D and D' are mutually exclusive. Once the assumptions are sufficiently spelled out, it's a matter of finding one that seems suceptible to questioning -- a chink in the armor of the conflict.

Also known as a conflict cloud, a dilemma cloud, or a conflict resolution diagram, the Evaporating Cloud provides a solvable verbalization of a conflicted situation where solvable is defined as "win-win." Probably the most multi-purpose of the Thinking Processes, the cloud is appropriate for dealing with tough personal decisions, interpersonal conflict or negotiation (think of requirements as needs and prerequisites as wants), and resolution of what I like to call "systemic conflicts" and by extension, a sort of "root conflict analysis."

Speaking of "systemic conflicts," new research/experience in the use of this tool is showing that if a group can verbalize the various dilemmas that they face in dealing with both their day-to-day and long-term efforts via clouds, the results can go a long way to delivering widespread favorable impact on their overall effectiveness. These individual conflicts usually turn out to be systemic conflicts, forcing people between "rocks and hard places" when they try to do the right thing for themselves, their individual departments, or the company as a whole. Often what seems to be the right thing for one of these entities results in a dilemma, the other side of which is doing the right thing for another aspect of the endeavor but that is in conflict with the first action. A group's behavior (its culture as well as its practices) is defined by the accumulation of these dilemmas and how they tend to resolve them.

It may sound strange, but when you look at these dilemmas together, they seem to exhibit a "fractal" nature in their self-similarity. There is very often (actually almost always) some generic conflict/dilemma that they can be translated to. When this generic conflict is identified and addressed appropriately, it can lead quickly to a coherent and consistent set of actions (including appropriate training, measures, and policies) that will result in the mitigation, if not elimination, of the various individual issues being faced throughout the organization.

These various applications of the cloud involve both construction and communication. The different uses imply different starting points for building the cloud. Those approaches are best left for another time (or another venue, like a workshop) so I can write about the other tools in my favorite toolkit.

If stuck on the proverbial desert island of problem solving, I think it's obvious that the cloud is the tool I would want to have in my pocket, because at the core of almost any problem or decision (either minute and personal or broad and strategic) that one faces (or that a group faces) is the dilemma of doing one thing or another, pursuing one direction or another, going for D or for D', even when its as simple as doing something or doing nothing. The cloud tells you that there really isn't a choice involved at all, it's only a matter of examining the assumptions that make you think there is a choice.


Tool 2 -- The Current Reality Tree (CRT)

The CRT is a sufficiency-based logic (if..., then...) tool that is used to fully describe an existing situation. Its purpose is to understand (only to the level of detail necessary for the group to achieve consensus) how the various issues and problems they face are related to each other, to their policies, measurements, and practices and to the generic/root/core conflict identified through the process I described in the discussion of the Evaporating Cloud tool. This understanding provides the guidance for developing a solution, as understanding why X leads to an undesirable Y provides guidance for inserting new actions to either replace X or to cause it to result in a favorable Z instead.

The structure of a CRT is hard to draw in the text based format of email, but consists of connected clusters of statements associated with the situation. The connections are "if..., then..." or "if...and if...and if..., then..." cause and effect relationships. (Graphically, they are statements connected by arrows. Note that I have included similar diagrams in the descriptions of other tools -- FRT and NBR -- below.) These clusters are strung together as effects become causes of other effects. The CRT usually has at it's base a variant of a generic cloud, and higher up in the tree, most if not all of the subject matter's stake holders' symptoms/problems/issues linked in as effects stemming from stuff the root.

As we are discussing problem solving tools here, it should be mentioned that from a group participation point of view, the CRT is also thought of as a communication and clarification tool. Its construction is not really suited for a group activity. It is usually best if it is built by one person, or a very, very small group, familiar with the subject matter on their own, and then presented to the group for scrutiny and clarification. An alternative approach to using it is to have the individual members of the group build pieces of a CRT related to their area of expertise, and then use the group presentation and scrutiny to merge the pieces into a whole. Construction of a CRT is best as an individual process, scrutiny and clarification is most effective with group effort and input.

A well-built CRT will confirm that your suspect generic conflict (or a modification of it) is indeed at the root of the originally identified problems and it will serve as guidance for developing a new view of future reality (vision) to replace the current.

The combination of the core/root/generic conflict (the Evaporating Cloud) and the confirmation of the CRT linking it to the particular range of issues facing the group answers the first question that groups come together to address...WHAT TO CHANGE?


Tool 3 -- The Future Reality Tree (FRT)

The FRT is similar to the CRT in structure, but with new proposed actions, policies, and behaviors injected into it in order to create a new vision of the future reality of the system.

The power of the logical "if-then" construction is that if any one of the lower-level causes are removed or mitigated, everything that is above it is subject to change. If you can develop various "injections" as new causes, then you can, through restatements of the subsequent logic, predict and direct changes to the resultant effects. The classic example of how this sufficiency logic works is:

Code:
A CRT:                         AN FRT:
          I have                      I don't have
          a fire                         a fire
            ^                              ^
           /|\                            /|\
          / | \                          / | \
         /  |  \                        /  |  \
        /   |   \                      /   |   \
       /    |    \                    /    |    \
      /     |     \                  /     |     \
     /      |      \                /      |      \
I have   I have    I have       I have   I have    I don't have
 fuel   ignition   oxygen        fuel   ignition   oxygen in contact
                                                   with the fuel
 

Kevin Mader

One of THE Original Covers!
Leader
Admin
(Part 2 Added Here)



If any one of the three "ifs" of the CRT are removed or modified, the "then" may be removed from consideration as a problem. We might choose to develop a system in which fuel and sources of ignition are isolated from one another to prevent fires. Or if the problem is that a fire exists, we may choose to remove the oxygen by covering the fire with water, CO2, or a blanket. These are all possible injections. (If only all the "fire-fighting" we do were so clear cut! But maybe it can be almost so.) Even in more complex real-life issues, a careful analysis of assumptions, which in this kind of construction become more "ifs" arrowed into the "then," which become more possible sources for things to remove by the "injection" of new actions, policies, or behaviors.

If the CRT is based in a generic conflict, then the initial injection comes from the "out-of-the-5-sided-box" solution of that conflict -- the idea that stems from addressing questionable assumptions. (If the CRT was developed simply from linking the various undesirable effects (as it used to be done in the process before the discovery of the generic conflict's existence), then the core problem at the base of the CRT might be a single statement in the tree. The best way to deal with that result is to do a cloud on that statement.)

The objective of the FRT is to communicate a vision of how to change the undesirable effects found in the CRT to desirable effects. Again, like a CRT, construction is best done by individuals or very small groups, while the most effective use of group interaction (and that gains from experienced facilitation) is in scrutiny, clarification, and completion of the solution. The FRT is the first step to address the second step in problem solving, figuring out WHAT TO CHANGE TO.


Tool 4 -- The Negative Branch Reservation (NBR)

When a proposal to solve a problem is offered by a member of a group, whether in the form of a seemingly complete FRT or in the form of a standalone idea thrown out on the table, there are frequently concerns or reservations raised on the part of other members of the group. In the lingo of the Thinking Processes, a RESERVATION exists that if we act on an injection in the Future Reality TREE, there will result a BRANCH that leads to an undesirable, NEGATIVE result. Hence, the "Negative Branch Reservation" or NBR.

The key to "trimming the negative branch" again lies in the conversion of internalized intuition into logical if-then steps that can be rationally discussed while avoiding the feeling of "constructive criticism" or more blatant "pot-shots" aimed at the proposal.

The "if-thens" must link the proposed action with the suspected negative outcome. Then we can again apply assumption searches to the arrows, especially those that are merging arrows, not directly related to the initial proposal, in order to find a new injection - a new arrow that will change the outcome of concern. In the following example, it is determined that by instituting a new policy, we will be able to achieve something good for the organization.

Code:
             We don't really         We may get stuff
             get the good stuff      worse than we have
             we expect               now
                     ^              ^
                      \            /
                       \          /
Desired good        The policy may
stuff happens       be misinterpreted
     ^                    ^^
     |                   / |
    ...                 /  |
     |      ___________/   |
     |     /               |
     |    /      Not everyone
     |   /       in the organization
We put a new     understands the
policy into      rationale for the
place.           policy.

In this simple negative branch, it's easy to see that to complete the solution, i.e., to get not only the desired good stuff, but to avoid the possible negative consequences of our action we might want to replace the lack of understanding of the policy with another action involving education and explanation of the purpose of the policy. By doing so, we avoid the possible misinterpretation and subsequent bad stuff.

As a standalone tool, the NBR ranks right up there with the Evaporating Cloud in everyday usefulness in basic facilitation of problem avoidance. The cloud deals with conflicts and dilemmas and the NBR deals with doubts and concerns. They both aid communication so that the conflict or concern can be effectively and efficiently dealt with.

In terms of group accomplishment, the NBRs brought up by group members serve to complete the solution developed in an FRT. It also provides a route to buy-in for participants as their contribution to the solution (in the form of actions required to trim their NBRs) gives them a sense of ownership of (at least part of) the overall solution. Actually, even if starting with a single proposal, the identification and solution of NBRs could result in an FRT built on that proposal as open and unguarded discussion of concerns builds upon it.

(Some "system-thinking" aficionados may see similarities to FRTs and NBRs in causal loops. Indeed, complete CRTs and FRTs for complex systems do frequently contain loops of causality. In CRTs, these loops most often serve to perpetuate undesirable stuff. In well-designed FRTs, loops will be consciously looked for and strengthened so that they will contribute to getting more and more of the desired outcomes.)

The combination of the FRT and NBRs completes the answer to the group objective of determining TO WHAT TO CHANGE TO.


Tool 5 -- The Prerequisite Tree (PRT)

OK. We have a solution defined in terms of a vision and strategy that should achieve it (the complete FRT, augmented by the results of adding injections to trim NBRs), but we also have a whole pile of stuff blocking us from doing this part or that part of the strategy. Indeed, for some of the things we've identified as injections in the FRT, we may have no idea whatsoever how to make happen.

People are great at finding excuses why something can't be done. In more politically correct language, we refer to that skill as identifying obstacles.

The Prerequisite Tree (PRT) takes advantage of people's natural propensity and ability to point out why something can't get done. The first step in building a PRT (after identifying the team's ambitious objective) is to collect all the obstacles that the group can come up with. Then each individual identifies an "intermediate objective" (IO) that would overcome or make moot the obstacle they raised. (After all, the person who comes up with an obstacle has the most intuition about what it would take to address it.) Once all the IOs are identified, the obstacles are used to sequence the IOs into a network that becomes the plan to achieve the objective. Team effort is focused appropriately, since the network points the group to start on those IOs that don't depend on others, and only when they are done, they know they can move on to the next because they've overcome an obstacle that was blocking them.

A PRT defines what needs to be done (necessity logic) in what order to accomplish the ultimate ambitious objective.

This is a painless way of identifying which "bites of the elephant" we'll gnaw on first in our attempt to consume the whole thing. As a group effort, this process benefits (as does the solicitation of NBRs as reasons we shouldn't take a particular path of action) from the diverse and divergent views of the group's members. The more obstacles that are raised, the more complete the implementation plan of HOW TO MAKE THE CHANGE HAPPEN will be, resulting in fewer surprises along the way.


Tool 6 -- The Transition Tree (TrT)

This last tool further supports the need to describe HOW TO MAKE THE CHANGE HAPPEN. Sometimes a plan is developed by a group for other people to use. Sometimes getting from one IO in a PRT to another requires a finer level of detail in terms of action and results. Including the TrT here for completeness of the list of TOC Thinking Processes, it may be a stretch to think of it as a facilitation tool, as it's really a communication and empowerment tool, allowing the recipient of it to follow a path of action with clear understanding of what to expect along the way and why to expect it.

It is a simple repetitive sufficiency logic construct that puts the actions/tasks in context with the objectives. Based on simple, "if-then" links, the Transition Tree includes the need for action, the action, the rationale for the action (why we expect the action to provide the desired result), that desired, expected result (or intermediate objective - IO), and then reason for the next need in a graphical format:

Code:
         Result
          (IO)
       ^   ^    ^
      /    |     \
     /     |      \
Action    Need    Rationale
           ^   ^
           |    \
           |     \
         Result    Reason for
          (IO)      next need
       ^   ^    ^
      /    |     \
     /     |      \
Action    Need    Rationale

The transition tree includes all the info you need to build a detailed action plan, assess its ability to deliver results, and includes those results to allow development of alternative actions...a real "results-oriented" task list that encourages "empowerment" to offer new solutions. It sure beats a simple "Do this, then do that, then..." list of tasks that we usually get for instructions.

Again -- I might not consider it to be a real "facilitation" tool like the others, but I include it to round out the TOC Thinking Processes.

SUMMARY -- TOOLS and CONTEXT

WHAT TO CHANGE
(Situation assessment, description of "current reality," and identification of the core problem or conflict and assumptions that sustain it -- diagnosis)

Tools: Evaporating Cloud, Generic Cloud Process, and Current Reality Tree to link undesirable effects to root causes or conflicts that are the most efficient/effective things to attack.


WHAT TO CHANGE TO
(Verbalization of vision/solution and description of strategy to attain the desired state -- prescription, decision making, and solution development)

Tools: Evaporating Cloud to identify an out-of-the-box starting point, Future Reality Tree to flesh out the strategy to turn undesirable effects into desirable outcomes, and the Negative Branch Reservation to complete that strategy/vision by adding things needed to avoid unintended negative consequences.


HOW TO MAKE THE CHANGE HAPPEN
(Development of detailed plans and tactics that will clarify what needs to happen and synchronize the efforts of the group in the implementation of the strategy -- planning, team-building)

Tools: Prerequisite Tree to turn obstacles into an implementation plan so that ambitious outcomes can be achieved. The building of a plan as a group, based on individual input of foreseen obstacles, allows the team to become synchronized in its understanding of the task ahead of them and how their parts fit in to the whole. Transition Tree to (when necessary) get into deeper levels of detail for paths of action, relating them to expected outcomes along the way.


In addition to this comprehensive and consistent approach to making the right change happen, the use of clouds and NBRs as the starting point for assumption checking, and even the quick-and-dirty building of PRTs for planning become second nature to those that become familiar with the tools.

-- Frank Patrick

"Difference of opinion leads to inquiry, and inquiry to the truth."
--- Thomas Jefferson

[This message has been edited by Marc Smith (edited 12-13-98).]

________________________________
Marc,

At a quick glance, it looks good. I will have to give it a closer read. My opinion is that it serves up some techniques that if applied correctly will yeild good results. Unfortunately, these tools will likely be left in the toolbox. Because of the realitive light exposure, only the individuals aware of their existance will use them to potential. I must admit that I have tools that I have lost, but enjoy reminders like this posting that let me find them again.

Back to the group...
 

Randy

Super Moderator
I think at one time or another I have and have seen every bit of this used.

I think many of the above problem solving solutions work in the same way as the situational ethics or quality does that I talked about a while back.

"Whatever works at the time for the goal desired" That's a quote of mine. Feel free to use it freely without charge.
 

Marc

Fully vaccinated are you?
Leader
From: "Michael S" - Philips.com
Newsgroups: misc.industry.quality
Subject: Re: How can we motivate people about quality?
Date: Thu, 26 Apr 2001 14:01:10 +0200
Organization: Customer of UUNET Deutschland GmbH

To give you an idea what I am talking about:

Item A) is concerned with the "principle of increasing ideality". You will find details when you look for TRIZ. TRIZ, a russian acronym, stands for "a Theory to Resolve Inventive Problems". 'Inventive Problem' is a synonym for a very, very difficult problem: those we like to call 'impossible to solve'.

The good news: most problems only appear to be difficult, due to our perception of the situation. TRIZ is about breaking these psychological barriers. TRIZ is about improving the quality of thinking.

One of the TRIZ-findings is: any technical system, organizations etc. evolves in such a way, that it's ideality increase over time (or it disappears).

Ideality means: the ratio between all good and all bad things:

Ideality = (sum of all usefull things) / (sum of all harmfull things)

So the ideality of Nicolas is quite low at the moment:

usefull: vision of the QMS
harmfull: no info released
QMS refused
Nicolas is hurt or punished by management
no or low support from the team

So Ideality is sth. like I=1/4 at the moment.

How to improve?

Eliminate harmfull parts and strenghten usefull parts of the problem.

How to do that? Well, you can make your own suggestions. In cases, where this is not possible use the generalized ways to improve usefull action (items a) and b) ) and use generalized ways to eliminate harfull actions (items c) and d) ) [you have to know about TRIZ, perhaps].

For example, if Nicolas (or anybody here in the newsgroup) can find a way to *insulate* the harmful action from Management from Nicolas (item G) e) ), Ideality improves:

usefull: vision of the QMS
harmfull: no info released
QMS refused
no or low support from the team

to about I=1/3. And so on.

So please suggest ways, how Nicolas could put sth. between him and Management, which stops hurting him AND which does not deteriorate any usefull function or creates a new harmfull function. This insulator can be e.g. a person, an organizational effect, a procedure, an agreement and so on.

Now, what is the most ideal situation we can think of? Be creative! Think out of the box!

Well, in the most ideal case we managed to eliminate ALL harm and have ALL usefull things of the system. Ideality approaches: infinity.

The concept of Ideality is a very strong thinking tool from TRIZ. It gives us direction towards very strong solutions. It is the ultimate result from TRIZ, applied to difficult problems. In its extreme:

* 'no harmfull things are present' means 'the system is actually no
longer there'
BUT
* we have all its benefits, all usefull things from the system

So instead of developping, installing, mantaining and improving the QMS over time (years, decades) think *today* of this process AND finally eliminate the QMS in your thoughts, while preserving its usefull functions. If you manage to do this, you will save man-decades of work and trouble. The QMS will disappear anyway during the evolution of the company we talk about (because it performs only an auxilliary function: it may increase the usefull part a bit, but it has all kinds of new harmfull parts: procedures, documents, Audits, complaints, errors, ...).

So, look for ways to create:

* an absent QMS, which provides
* all the benefits of a QMS

If this actually can not be achieved, do a little less (this is inventive principle # 16 "excess or shortage"): approximate this Ideal QMS. Allow a little bit of harm and have not all the usefull things from it. E.g.:

usefull: smooth business process
very low complaint rate from customers
very high profit

harmfull: maintanance cost of QMS
complaints from customers

(I ~= 3/2 in this case; you may also measure it in units of money, if you prefer).


I hope you understand a bit better, now. Maybe I should have explained a little bit more. However, I found that the level of details and explainations from my previous posting worked well with colleagues from my company (which, in fact, does provide many creative individuals).


BTW: the initial question was "how to motivate people about quality". Ok, now we can suggest a more efficient direction to look for:

* the Ideal QMS installs ITSELF.

There is no team needed, no motivation, nothing else. The (absent, but beneficial) QMS installs ITSELF, nothing else is needed. Find ways to approach this ideal situation, step by step.

Impossible? Ok, than find ways to install a less Ideal QMS almost by ITSELF. And so on.

I wish you a nice day.

Examples:

During the last century we used a rigid, long stick to point at things at the blackboard. This device has some usefull and some harmfull part:

usefull: to point at something far away
harmfull: to complicate transportation (you can not put it into your
pocket)

The ideal stick:

* the stick is no longer there
BUT
* we have the usefull funtion of the stick "to point at a distant
object".

Real-life solutions:

1) the segmented stick: by shifting metal tubes into each other (inventive principle #7 "nesting") the stick can be made long for pointing AND short for transport.

2) translucent pointers appeared for overhead projectors. They are short and can be put on an overhead sheet. The shadow points at the object.

3) laser pointers are extremely short and can point at extremely distant objects.

4) no pointer at all: by the design of the objects on the sheet the object points at itself: it becomes self-evident over a very long distance of projection.

5) Powerpoints animation fetaures can be regarded as a subset of number 4). It provides a stick (the stick-function), which is no longer there. This is a common pattern in innovation: The object disappears and its usefull function is transferred to another available object. Ideality increases.
 
Top Bottom