Tag: Effective Problem Solving

How to Solve Problems with Idea Maps

FreeMind 0.9.0 RC4 - Mind Map with User Icons
Image via Wikipedia

Problem solving is a problem in itself for many companies and at times can be one of the most daunting tasks to undertake during the course of an otherwise regular work day.

For some, problems seldom occur while for others this may, unfortunately, be a daily activity.  Since problem solving is not usually part of the typical daily agenda of “routine” activities, our ability to find the time and solve them efficiently and effectively is compromised.

For many, just finding time seems to be one of the greatest challenges and perhaps a problem to be solved in itself.  Sweeping problems under the rug may be efficient but it is certainly not effective.  (So … broom is not the solution we’re proposing).

Using IDEA Mapping Techniques can help you solve problems effectively and efficiently.  IDEA Maps, Process Maps, and Mind Maps are variations on a theme.  We may use the terms interchangeably in the discussion that follows.

Background:

While there are several different approaches and “forms” that can be used to manage the overall problem solving process, the two most critical steps that will determine the effectiveness of the solution are:

  1. Define a Clear and Concise Problem Description / Statement
  2. Determine the Root Cause(s) of the problem defined by the Problem Statement.

While the first step seems relatively simple, the second step requires a little more effort.  There are at least two (2) root causes for most problems that stem from two simple questions:

  • Why Made?
  • Why Shipped?

These questions imply that defective product was made for a reason (process) and it was shipped to the customer undetected (system).  In other words, the customer is not protected from receipt of defective product.

The root cause analysis process forms the basis for all subsequent problem solving activities, including verification, interim and long term corrective actions.  A lot of time can be wasted simply because the real root causes were never identified.

Problem Solving Tools for Root Cause Analysis:

Many different tools can be deployed during the Root Cause Analysis process including Ishikawa Diagrams (Fishbone Diagrams), 5 Why (discussed in a previous post), Fault Tree Analysis, Q&A (Question Board), and Brain Storming to name just a few.

Mind Mapping or Process Mapping is a technique that provides an unconstrained approach to the thinking process for multiple input and contribution streams.  Maps can also be used to identify interactions or relationships to other elements.

Mind Mapping (Process Mapping)

The center of the map contains the problem statement.  We then surround the problem statement with potential inputs or contributors to the problem.  These statements in turn become the “center” of additional levels of inputs and contributors.  In some respects, the process map can be very similar to a Bloom Diagram and certainly supports the logic found with fishbone diagrams.

The   The draw back to “Mapping” is that most are usually developed on Whiteboards and not easily or readily translated into a software solution.

Software Solutions and Templates

While there are many spreadsheet based solutions, few provide an effective interface to support the use of mapping techniques.  Even most fishbone diagrams developed in Excel are quirky and awkward at best.

While we typically do not endorse specific software solutions, however, FREEMIND is one software that we consider to be among the best of available solutions and can be downloaded free of charge.  The download and installation process only requires a few minutes.

The developers of FREEMIND provide a clean, intuitive solution for creating and maintaining process or mind maps.  While other commercial packages are available, FreeMind is more than capable of handling most problem solving challenges and quite simply is time and money well saved.

The FreeMind homepage provides a better description of the software and it’s capabilities than we could provide here.  Our goal was to introduce “Mapping” as an effective and efficient tool that can be used in the problem solving process.

After spending some time with the software, you will quickly discover that there are many other opportunities where this software can serve you.  We have a mind map that we use to manage weekly and daily reports, another for key metrics, and yet another for our business structure.  The ability to use hyperlinks makes it an easy process to access external reports and resources .

The FreeMind main page provides an excellent overview and provides examples of their software in action.  This is definitely worth looking into and may just save some time for real problem solving.

We are presently using FreeMind version 0.9.0 RC 6.

Home: http://freemind.sourceforge.net/

Copyright 2000-2009 Joerg Mueller, Daniel Polansky, Christian Foltin, Dimitry Polivaev, and others.

Click here to see a sample process map to achieve delivery of 100% on time – in full:  Mapping with FreeMind.  We have also uploaded two documents (one of the original map and a word document showing a pictorial of the mind maps we created) into our Free Downloads box.  See the ORANGE box on the sidebar to get your copy.

If you have a copy of FreeMind, simply change the extension on our Delivery file from “.txt” to “.mm”  Of course, don’t type the quotes.  This is just a sample for example purposes only.  Feel free to edit or modify these files  in any manner you choose.

If you would like to learn more about IDEA Mapping we would encourage you to also read Idea Mapping – How to Access Your Hidden Brain Power, Learn Faster, Remember More, and Achieve Success in Business by author Jamie Nast (twitter:  @JamieNast) or you can visit the website at:  http://www.ideamappingsuccess.com/.

Click here to review or purchase your copy of Idea Mapping: How to Access Your Hidden Brain Power, Learn Faster, Remember More, and Achieve Success in Business

Until Next Time – STAY lean!

IDEA Mapping, Published by John Wiley & Sons, Inc, Hoboken, New Jersey, Published simultaneously in Canada (ISBN-13:  978-0-471-78862-1, ISBN-10:  0-471-78862-7), 268 pages.  The book includes a companion CD-ROM featuring a 21 day trial for Mindjet MindManager 6.
Advertisements

How to use the 5 WHY approach

Schema of the Process of problem solving. Base...
Image via Wikipedia

The 5 WHY technique, developed by Sakichi Toyoda, is one of the core problem solving tools used by Toyota Motor Corporation and has been adopted and embraced by numerous companies all over the globe.  This technique is unconstrained, providing the team with a high degree of freedom in their thinking process.

As we suggested in our “How to Improve OEE” post, the 5 WHY system is simple in principle.  This simplicity may also be the downfall of this technique unless you take the time to understand and apply the process correctly.  Other problem solving tools, such as Cause and Effect diagrams, allow for the development of multiple solution threads, in turn creating the potential for multiple solutions.

Some root-cause analysis experts have correctly identified some of the short comings presented by the 5-WHY technique including:

  1. The approach is not repeatable – One problem, different teams, different solutions.
  2. The scope of the investigation is constrained by the experience of the team.
  3. The process is self directing based on the evolution of the “WHY + Answer” series.
  4. The TRUE Root Cause may never be identified – Symptoms may be confused for Root Causes.
  5. The inference that a root cause can be determined by a 5 tier “Why + Answer” series.
  6. The Problem Statement defines the Point of Entry. It is imperative to define where the real problem begins.

We would argue that any problem solving or root-cause analysis tool is subject to some short falls in one form or another.  Perhaps even in problem solving there is no definitive solution.  Different problems require different tools and perhaps even different approaches.  In the automotive industry, each customer has a different variation on the problem solving approach to be used and prescribe various tools to be used in the problem solving process.

For this reason, most companies do not rely on one single technique to approach their problem solving challenges.  We would also argue that most companies are typically well versed in their processes (equipment and machines), products, and applications.  As a result, having the right people on the team will minimize the experience concerns.  There is no reason not to include outside expertise in or outside of your current industry.

One concern that can be dismissed from the above list of short comings is the inference that the solution can be found by a 5 tier “Why + Answer” series.  There is no rule as to how many times the “Why + Answer” series should be executed.  Although five times is typical and recommended, some problems may require even deeper levels.  We recommend that you keep going until you have identified a root cause for the problem that when acted upon will prevent its recurrence.

The TRICK:

The technique that we propose in this post will at least provide a method to validate the logic used to arrive at the root cause.  Most 5-WHY posts, web sites, articles, or extracts on the topic seem to focus on a top-down or deductive “Why + Answer” logic sequence.  The challenge then is to have some way to check the “answer” to see if it actually fits.

A simple way to validate the top down logic is to read the analysis in reverse order, from the bottom up, substituting the question WHY with the words “Because” or “Therefore.”  To demonstrate the technique we’ll use an example based on a problem sequence presented in Wikipedia:

I am late for work (the problem):

  1. Why? – My car will not start. (The Real Problem)
  2. Why? – The battery is dead.
  3. Why? – The alternator is not working.
  4. Why? – The alternator belt is broken.
  5. Why? – The alternator belt was well beyond its useful service life and was never replaced.
  6. Why? – The car was not maintained according to the recommended service schedule. (Root Cause)

You probably noticed that we used a 6 “Why + Answer” series instead of 5.  We did this deliberately to demonstrate that 5 WHY is a guideline and not a rule.  Keep asking WHY until you find a definitive root cause to the problem.  We could keep going to determine why the car was not maintained and so on to eventually uncover some childhood fear of commitment but that is beyond the scope of our example.

The CROSS CHECK – Root Cause Analysis Validation

Root Cause: The car was not maintained according to the recommended service schedule.

  1. Therefore, the alternator belt was well beyond its useful service life and was never replaced.
  2. Therefore, the alternator belt is broken.
  3. Therefore, the alternator is not working.
  4. Therefore, the battery is dead.
  5. Therefore, the car will not start. (The Real Problem)
  6. Therefore, I will be late for work.

Does the reverse logic make sense to you?  It seems to fit.  Does it sound like the owner of the car needed to be a mechanic or at least know one?  When it comes to car trouble, we don’t seem too concerned about going to the outside experts (the mechanic) to get it fixed.  Why do some companies fail to recognize that experts also exist outside of their business as well?  In some cases, proprietary or intellectual knowledge would preclude calling in outside resources.  Barring that, some outside expertise can certainly bring a different perspective to the problem at hand.

Caution!  Stick to the Problem – Don’t Assign Blame

The original Wikipedia example identified the root cause as, “I have not been maintaining my car according to the recommended service schedule.”  It would be too easy for someone to say, “Aha, it’s entirely your fault.  If you only took better care of your things you wouldn’t have been in this predicament.”  For this reason, we presented the case based on the facts.  It’s not WHO it’s WHAT.  This approach also tempers emotions and keeps the team focused on the problem and the solution.

Where do we start? Problem Entry Points

You have likely noted that the problem statement is the key to establishing a starting point for the 5 WHY process.  A problem may have different entry points depending on what stage you become involved:

Entry Point Problem Statement
You Late For Work
Service Manager The car will not start
Mechanic The battery is dead
Belt Supplier The alternator belt is broken

Product Recalls and Warranty Returns are typical examples of where you may find multi-level 5 WHYs.  Ultimately the suppliers of most products, like the Belt Supplier in our example, will also complete a 5 WHY.  This is typically the case for most Tier I automotive suppliers.

WHY MAPS / TREES.

The one drawback or downfall of the 5 Why process as presented above and also used by most companies is the suggestion that a single “WHY + Answer” series will evolve into a neat single root cause.  Our experience suggests that this is far from reality.  We typically present the single series as part of the final solution, however, we can assure you that multiple root cause / solution threads were developed before arriving at the final result.

We use the WHY MAP (WHY TREE) as a tool that allows us to pursue multiple thought threads simultaneously.  Pursuing multiple threads also stimulates new ideas and potential causes.  In some cases the root cause analysis threads lead to the same or common root cause.  Then it is a matter of selecting the most likely root cause.

Tip:

Problem solving TREES come under many different names including Why-Tree, Cause Tree, Root Cause Tree, Causal Factor Tree, Why Staircase Tree, and Cause Map to name a few of them.  As you can see from the names, they all serve to create, stimulate, and propagate ideas.

Regardless of the tool you use, finding the true root cause and ultimately the solution to resolve it is the key to your problem solving success.

We trust this post will provide you with some insight to using the 5-WHY approach for problem solving and will serve as a useful tool to improve your OEE.

More on this series to follow in our next post.

Until Next Time – STAY lean!


How to Improve OEE – Any Questions?

Ask any Quality or Engineering manager and they will tell you that measurement systems are valuable tools to identify problems and opportunities.  The measurement system itself is not the answer – it is the data source, the EVIDENCE that drives the questions.  It is a part of the discovery and validation process to confirm the opportunity or problem and the effectiveness of the solutions to resolve it.

A well integrated OEE system should provide the data to answer the questions on everyone’s mind, “What do we need to do to improve?” or “Why aren’t we improving?”  The simple answer is, “We need to fix it.”  Of course the real question may not be, “What do we need to fix?” but, “Why did it break?”

Yes, we will likely have to replace the part(s) that failed to get the line back up and running, but what really caused the failure to occur?  What was the real root cause?  This introductory post to problem solving and root cause analysis will kick start some of the techniques used to solve problems effectively.

The Problem Statement:

The key to effective problem solving starts with identifying the problem to be solved.  This is typically a brief statement describing the problem.  For external concerns, the problem is usually stated in customer terms.

This post presents some simple examples of problems to be solved.  You will quickly discover that defining the problem may not be as simple as it looks.  We will discuss this in more depth in our future posts.

Root Cause Analysis

Identifying the real root cause(s) for the failure is the secret to successful problem solving.  The method you use to arrive at the root cause should allow you to confirm and validate your solution before taking action.  Here is an important point to remember:

Do not confuse symptoms with root causes.  

For example, you are driving down the road and suddenly find yourself struggling to maintain control of your vehicle.  Your expert driving skills allow you to pull over and stop on the side of the road.  You get out of the car and walk around to discover that you have a flat tire.  The flat tire is a symptom – not the root cause.

As luck would have it, a police officer who just happened to be following you in an unmarked car, notices your sudden erratic driving behavior and charges you with recklessness and careless driving.  Since none of the tires on the police car are flat, the officer presumes the condition of your vehicle is the direct result of your poor driving skills and bad habits after many years on the road.  Another point to remember:

Do not jump to conclusions

You, like many people, would argue that your many years of driving provided you with the experience necessary to avert danger.  The officer quickly recognizes that your many years of experience have caused you to lose perspective of the potential hazards of driving.  The officer advises that your driving record shows no record of any tickets or accidents and clearly suggests that you have had very few “experiences” with the law and minimal exposure to poor road conditions.

The officer proceeds to charge you, the operator, because you simply weren’t paying attention to the conditions and potential hazards of the road.  You are given a ticket to serve as a reminder to pay more attention to the road and to be mindful of your driving habits in the future.  Then to add insult to injury, the officer advises you to fix your tire and drive carefully. 

Unforgiving of the circumstances and since quota’s have to be met, the charges stand and you find yourself on your way to court.  As you sit in your vehicle, stunned that you just got a ticket for getting a flat tire, you are conflicted and fuming because the officer blamed you, your poor driving skills, and your bad habits for driving recklessly down the road!  The following tip will help you remember:

Operator Error is not a Root Cause

Many times, management is too quick to attribute the root cause to operator error.

5 WHY Analysis

One of the best methods for identifying the real root cause is the 5-Why approach.  The concept of asking the question “WHY?” five times is quite simple.  In practice though, you will find it may not be that easy.  Why?  Because the wrong answer will lead you through a continuing series of wrong answers that ultimately lead to the wrong conclusion.

There is always more than one answer – Which one is correct?

Referring back to our example of the flat tire, you now need an argument to absolve yourself of any blame for the incident on the highway.  In court, the judge asks, “How you plead to the charges before you?”  You answer, “Not Guilty your honor.”

  1. Why?  While I was driving down the road, I got a flat tire.
  2. Why?  Because all the air ran out of my tire.
  3. Why?  Because there was a hole in it.
  4. Why?  Because the tire didn’t have anti-puncture technology.
  5. Why?  Because the manufacturer didn’t design it properly.

Were it not for my expert driving skills, this situation could have been much worse.  As it was, using my superior driving skills, I successfully managed to maneuver my vehicle, without incident, to the side of the road, averting what could have been a disastrous crash.  Therefore, I request to be completely absolved of any and all wrongful doing and I am filing a class action suit against the tire manufacturer to cover court costs, lost wages, and damages as well as my emotional stress.

Clearly not satisfied, the judge requests you to take a 10 minute break to rethink your case.  On your return to the courtroom, you are prepared to present the following argument:

  1. Why?  While I was driving down the road, I got a flat tire.
  2. Why?  Because all the air ran out of my tire.
  3. Why?  Because there was a hole in it.
  4. Why?  Because there was a nail on the road.
  5. Why?  Because the government refuses to keep the highways clean.

Were it not for my expert driving skills, this situation could have been much worse.  As it was, using my superior driving skills, I successfully managed to maneuver my vehicle, without incident, to the side of the road, averting what could have been a disastrous crash.  Therefore, I am filing a class action suit against the government to cover for court costs, lost wages, and damages as well as my emotional stress.  To resolve this matter quickly, I request that all charges be dropped and I in turn will drop my counter-claim.

The purpose of the above example was to demonstrate how the answer to the question – WHY? – can lead to completely different conclusions.  On one hand we’re ready to sue the tire manufacturer and on the other, we’re ready to take on the government.  If there was indeed a nail on the road, how did it get there?

Don’t Assign Blame

Solving problems and getting to the root cause is not about assigning blame to someone or something.  You can’t blame the government or the tire company for the fact that there was a nail on the road.  It is to easy to assign blame and it happens everywhere, everyday.  Perhaps the nail manufacturer should be sued as well for failing to provide adequate protections should the nail become lost or misplaced.

The question that wasn’t asked is, “Why was the nail on the road?”  The answer may be that it likely fell out of a board or from a truck or trailer that may have been carrying construction materials.  Again, being careful with the answer, we don’t want to come to the conclusion that nails should be banned completely.

On the other hand, it may be worthwhile to advise that all companies and contractors must make a reasonable effort and take appropriate precautions and measures to ensure that all loads are secure and free from loose raw materials.  Any nails must be placed in a sealed container and secured to the vehicle for the purpose of transport.  A maximum fine of $2,000.00 may be imposed and made payable to the “Operator Error Trust Fund.”

Leading the Witness:  The solution BIAS

STOP! – if you think you already know the answer – Stop!  We know that the right question doesn’t always lead to the right answer as we attempted to show in our example.  Another major pitfall is thinking we already have the answer and we just need to frame the questions and answers to support that conclusion.  This isn’t problem solving, this is creative story telling.  Don’t lead your team into following what “appears” to be a logical conclusion – be prepared to prove it.

Don’t Assume Anything – Follow the EVIDENCE

At a minimum, follow the evidence.  What is the data telling you?  It’s time to start thinking like a crime scene investigator (CSI) or good lawyer.  Asking questions and continuing to probe for answers is the secret to uncovering the less obvious and, more than likely, real solution.

Many OEE equipment / software integrators provide the ability to record and track downtime events in real time.  This data is extremely valuable for trouble shooting and problem solving; however, they are not necessarily root causes.  The integrators provide the capability to readily identify what part of the process failed or what is broken.  While this may be the cause of the line down condition, it is not the root cause of the problem.

Do not confuse the Point of Failure (Source) with the Root Cause

Don’t fall into this trap:

  • Supervisor:  “The OEE system report showed that we lost two hours on the paint line last night.”
  • Maintenance:  “Yeah, I saw the report too.  This OEE system tracks everything!”
  • Supervisor:  “Why did the line go down?”
  • Maintenance:  “The A-Tank feed pump overheated.  The OEE system told us exactly which pump failed.  It saved us a ton of time.”
  • Supervisor:  “What did you do?”
  • Maintenance:  “Oh, we replaced it.  The line is running fine now.”
  • Supervisor:  “OK, that’s good.  Thanks.”

End of conversation.

So, WHY did the pump overheat?  Some questions just never get asked, but I’m sure the OEE will be just fine on the next shift.  We recognize that most effective TPM managers are sharper than this.  Our point is that not everyone is looking at the data from the same perspective.

We’ll discuss “How to Improve OEE” in more detail in our next post:  “How to use the 5 Why Approach.”

Until Next Time – STAY lean!