Is-Is Not Matrix

Gary Cox is a great Quality resource in addition to being very funny! gcox@barringtongrp.ca

REFLECTION: FOR STUDENTS: Are you focusing on root causes or symptoms when addressing problem solving?

FOR ACADEMICS: Are you providing your students with the tools needed to comprehend the true root cause of problems so they may be mitigated?

FOR PROFESSIONALS/PRACTITIONERS: Is your organization allowing you find the true root cause of an issue before forcing the issue forward? This practice will hurt the business in the long run. Try to convince top management to allow all problems to be fully explored. Using COPQ may get their attention if it is documented properly.

Overview of Is – Is Not Matrix Tool

The Is – Is Not Matrix helps to identify where to start looking for causes, especially when the root cause may be hidden by multiple factors. By isolating the who, what, when, and where of a stated problem, you can compare the “is,” and the “is not” of the problem and narrow your investigation to factors that have an impact and eliminate factors with no effect.

IS-IS NOT Matrix Process

As the name implies, you begin by drawing out a matrix, as shown here, with the problem statement in the upper left corner, clearly defining the problem in a way that allows everyone to understand the issue being addressed (Tague, 2005).

This tool works best with a cross-functional group of four to eight people who represent all facets of the issue and an active facilitator who challenges statements made, such as “Do we have data to back that up?” and “Do we know that to be true?” (Rucker, 2010).

Is

After the team has agreed upon a concise, specific Problem definition, use the “Is” column to describe what occurred or occurs. Determine what objects are affected and what precisely occurs, being as specific as possible. Determine where the event occurs- Geographically, physically (as in department), or physically where on the object (top left of the page)- It can be a combination of all of these. Next comes the determination of When the event occurs. For best resolution, the team should come to a consensus (preferably using data) on when it first happened, when since, the pattern of occurrence detected, and, did this event occur in relation to any other events (before, during, or after)?

Determine How many or How much-the extent of the problem using the team consensus and available data. Severity is a good thing to capture for the group in order to help guide future decisions.

Determine who is involved, including to whom, by whom, and near whom does this type of event occur? At all cost do not use this as an opportunity to play the blame game. Only explore cause.

Is Not

After the “Is” column has been filled out, perform the same set of evaluations used for the “Is” column on the “Is Not” column to identify the circumstances that could occur but do not, using what, where, when, how many/much (extent), and who type questions.

Evaluation

Evaluate the “Is” / ” Is Not” columns to identify distinctions and possible consequences for the differences. Try to determine what changes have occurred, recording observations in the far right column.

Distinctions and Consequences

For each Distinction or Consequence, ask, “Does this relate to a change we are aware of?’ And “How could this have caused our problem?” Record all possible causes, including what may have caused the problem and how it did so.

Testing

Test all possible causes by asking, ‘does this explain every item in the “Is” and “Is Not” columns? The most likely causes will address every aspect of the problem.
If possible, plan an experiment to verify the cause(s) you have identified.

When data are not available to back up a position, ask yourself whether it could be quickly collected. To separate theories from opinions, determine if you could conduct an immediate experiment as proof? Add any results obtained from testing to the matrix (Tague, 2005) (Rucker, 2010)

Basic Example

The initial thought of mechanical issues was not chosen as it may have been the operator putting no or wrong antifreeze. This is where testing and data are critical, and why the correct members on the team will help solve the problem more effectively

Conclusion

For the best result, always be sure the team has a the problem statement in as concise and specific language as possible in order to focus on just one issue. It is also best to describe the problem as the lowest possible level (the example of “car will not start” was not a sterling example). The more focused the more likely this tool will yield results. Maximum detail should be utilized when describing the “is” and “is not”, and never be afraid to seek more data!

Processing…

Success! You're on the list.

Whoops! There was an error and we couldn't process your subscription. Please reload the page and try again.