B
y David L. HallowellWith the complexity of many of the tools in the Six Sigma kit, it is easy to look at tree diagrams as fairly simple and routine. Experience shows, though, that there are enough pitfalls encountered and benefits missed that it is worth consolidating a few time-won guidelines and tips about applying them and explanations on subtle ways they can become inadvertently blurred with one another.
The focus here is on four kinds of "trees" or hierarchical diagrams that become part of many Six Sigma projects:
Each of these trees has a specific thrust and strength that can be surprisingly challenging to capture when a project team tries to build one or more of them. The diagrams have enough similarities in the required data and the building processes that teams can tangle them up a bit – potentially dulling the result.
Getting the full strength from these simple tools requires special attention to what makes each unique; and requires vigilance on the part of the team during the tree's construction.
The table below outlines each type of tree diagram, providing information which helps differentiate the trees by style and function.
| Cause-and-Effect
Tree Diagram | Y-to-x
Tree Diagram | Functional
Tree Diagram | Abstraction
Tree Diagram |
| Application | Uncover root causes that are actionable – to change the problematic effect. | Identify and classify factors (independent variables) that may drive an important results variable. | Identifiy general and specific functionality that operates in concert in a product or process. The tree structure helps check for completeness and reports the analysis in ways that can hide or expose details appropriate to different audiences. | Distill fragments of data to find messages and themes that are not evident in raw data by itself. Tree powerfully and succienctly reports the insights derived by the team constructing it. |
| Starting Point | A documented effect | A results measure (dependent variable) | One or more functions delivered by a product or process | Facts that answer a theme question |
| Construction | Top Down: Starting with the effect, asking why in a nested and branching pattern to surface fundamental causes. | Top Down: Asking the question, "What factors may drive changes in the measure at the current node?" | From Top, Middle or Bottom: Organizing a group of connected functions from the general view to the detailed view. | Bottom Up: Understanding and grouping factual answers to a theme question using rules of abstraction. Discovering and reporting themes that may have been evident in raw data. |
| Node Wording | Describes factual situations without ambiguity | Describes factors (variables) that can change value | Uses positive, active verbs to describe the node's functionality | Uses factual report language, free of judgment, emotion or inference |
Cause-and-Effect Tree Diagrams
This is one of the original, tried-and-true, basic tools that needs little introduction. Beginning with an effect that has been observed and verified, a team repeatedly asks, "Why does this situation exist?" When each answer describes a situation that is at least a contributor, the "why" moves down a level to consider why that situation happens. When done well, this can lead a team from the original effect (like "less-than-expected gas mileage"), which is not directly actionable, to root causes that the team can do something about.
The art in building these trees is in crafting, at each level, the wording of answers to be factual, at the right level of detail, and within the team and project's area of concern. Those things together make each "why" meaningful and direct it to the next level down, toward root causes.
Too often, an answer that is too vague, judgmental and/or outside the team's area of influence (like "bad management" or "poor training") gets posted in the tree as in Figure 1. Such a node makes it hard to pose the next "why" – stifling progress on the drilldown on that branch. Figure 2 shows a better choice, with a factual answer in report language and in the scope of the project's area of concern. A next "why" can be usefully posed, surfacing further detail, as shown in Figure 4.
| Figure 1: Common Pitfall – Out-of-Scope Answer |
|  |
|
| Figure 2: Better – Detailed and in-Scope Answer |
|  |
|
|
|
Another common pitfall in cause-and-effect work is branching to answers that describe "the parts of" the problem (where it is, when, etc.) as in Figure 3. That does not answer the original "why" very well and it does not set things up for the next one. Better to revisit and reword such answers to more clearly propel the detail around "why."
| Figure 3: Another Pitfall – Branches That Do Not Answer the "Why" |
|  |
|
|
Y-to-x Flowdown Tree Diagram
A Y-to-x tree begins with an important results measure (the Y) and asks the question, "What factors drive this Y?" While that is not completely different than the cause-and-effect question, the thrust and content of this tree want to be distinctly different. Each node in the tree should describe a measure – a factor that can take on different values. Factors can describe measures that range from continuous (like time and capacity) to categorical (like small, medium and large) – but they should all describe measures.
Figure 4 is a part of a simple Y-to-x tree, cast in the same general subject area as the cause-and-effect tree in Figure 3. Even though the spirit of the inquiry is similar in each of these cases, by posing the question about driving factors, the Y-to-x tree calls for different language in the node labels, and it drives to a different kind of lower level result, with the identified x's. Each node should describe measure – a factor that can take on different values.
| Figure 4: Part of a Simple Y-to-x Tree |
|  |
|
|
Figure 5 shows part of a Y-to-x tree for a medical device, illustrating the value in sticking with measures all the way down to the lower level x's – as they can be classified as "controllable" or "uncontrollable" or "noise" factors. While the results Y is generally not a measure that can be influenced directly, the lower level x's should be. In DMAIC projects, controllable x's, with verified impact and in the team's sphere of influence, are used to drive the Y in the direction of project goals. In DFSS projects, the x's and their influences affect design decisions and adjustments to optimize performance during design and implementation.
While building Y-to-x trees, some teams are tempted to insert causes like "Getting a Good Enough Sample to Read" instead of a measure like "Sample Adequacy." While both phrases describe what is important, the tree is better served with labels that all read like factors that can take on different values.
| Figure 5: Section of Y-to-x Flowdown Tree for a Medical Device |
|  |
|
|
Functional Analysis Tree Diagrams
As noted, a Y-to-x flowdown tree focuses on the results measures and drivers connected with critical requirements. A related-but-different perspective is gained by identifying and organizing the important functionality in an emerging or existing product or process. This calls for a special "lens" that highlights the functions delivered. Figure 6 shows such a view, for the same system seen previously in Figure 5 through the "measures" lens.
Functional analysis as an engineering method dates way back, with verbs always used to precisely describe functions. More recently, object-oriented thinking has developed "use cases" which broaden the use (still centered on verbs) to software and business systems. (See Related Tools and Articles.)
| Figure 6: Section of Function Analysis Tree for Medical Device |
|  |
|
|
Figure 7 shows how trees can be reviewed and detailed by scanning each level asking "Are these the only causes, measures or functions that convey a complete picture?" Additional latent requirements were discovered, shown as functionality that increased the breadth and/or depth of some branches.
| Figure 7: Improved Functional Analysis Tree with Latent and More Detailed Functions Identified |
|  |
|
|
A functional tree it is much easier to read and review if each node label focuses on a positive, active verb (like "measuring," "gathering" or "reading" in Figure 7). If a team slips into labels that describe measures or where or how the functionality happens, the leader should pull the team back to the simple verb discipline.
Abstraction Tree Diagrams (KJ or Affinity)
A KJ (a language processing tool named for the initials of its originator, Jiro Kawakita) or properly done affinity diagram organizes facts in a tree-like hierarchy. Unique among the other tree tools considered here because they are built from the bottom up, a KJ applies the rules of abstraction discover and articulate key messages at the top of the tree in Figure 8. These few concepts or themes distill the meaning that may not be immediately evident when looking at the many lower level facts at the bottom of Figure 8.
Teams building a KJ tree may slip into "cause-and-effect" thinking, considering why things happen, instead of distilling how, when and where, as is required with a KJ tree. Every lower level in a KJ tree should be a good example of the data above, at the next lower level of abstraction. Figure 9 illustrates the concept – a ladder of abstraction which is not tied to cause and effect.
| Figure 8: Section of KJ Diagram (Abstraction Tree) |
|  |
|
|
| Figure 9: KJ Tree Follows the Ladder of Abstraction, Not Cause and Effect |
|  |
|
|
Conclusion: The Logic and Value of Tree Diagrams
The data and construction logic is what makes these four types of tree diagrams unique. This information should be valuable to project teams who have to build one of these familiar tools from time to time, as well as process owners and champions who need to fully understand the factors explained by each type of tree diagram.
About the Author: David L. Hallowell, a co-founder and managing partner of Six Sigma Advantage, Inc., has more than 20 years experience as an engineer, manager and Master Black Belt. As Digital's representative to Motorola's Six Sigma Research Institute, he worked on the original courseware for Black Belts and the application of Six Sigma to software. Mr. Hallowell has supported Six Sigma deployments worldwide. With a special focus on Design for Six Sigma, he has led development teams in the concept development and design of a number of commercial products. Mr. Hallowell has patents and publications in the area of microelectronics packaging and high speed interconnect. He has authored courses in software DFSS, design of experiments, C++ and computational intelligence tools. He co-authored Six Sigma Advantage's Black Belt, Green Belt and foundation curriculum. Mr. Hallowell can be reached at dhallowell@6siga.com.
