10 Common Problem Solving Mistakes

I’ve been noodling around about writing an article about 10 common problem solving mistakes. Before fleshing it out, I thought I’d share the list here to get your reactions.

In no particular order of importance (and without much explanation for now):

  1. Jumping to solutions (before understanding the problem or its root cause)
  2. Jumping to the root cause (without thorough enough analysis and observation)
  3. Not going to the “gemba” to talk to the people involved and to observe first hand
  4. Solving the wrong problem (the real problem isn’t what you think it is)
  5. Stating the problem as the lack of something (pre-supposing a countermeasure), such as “problem = we don’t have enough MRI machines” so the obvious countermeasure is “buy another MRI”
  6. Thinking of “solutions” instead of “countermeasures”
  7. Trying to fix others before fixing problems in your own circle of influence
  8. Not confirming that countermeasures really led to improvements
  9. Not confirming that the improvements are sustained over time
  10. Not reflecting on the learning that occurred during problem solving (focusing only on the results)

Which of these do you see as the most common problem-solving problems in your organization? Are these problems more prevalent in certain industries? If you comment, please share what industry you are in…


Thanks for reading! I’d love to hear your thoughts. Please scroll down to post a comment. Click here to receive posts via email.


Now Available – The updated, expanded, and revised 3rd Edition of Mark Graban’s Shingo Research Award-Winning Book Lean Hospitals: Improving Quality, Patient Safety, and Employee Engagement. You can buy the book today, including signed copies from the author.


Related Posts Plugin for WordPress, Blogger...
Please consider leaving a comment or sharing this post via social media.

Mark Graban's passion is creating a better, safer, more cost effective healthcare system for patients and better workplaces for all. Mark is a consultant, author, and speaker in the "Lean healthcare" methodology. He is author of the Shingo Award-winning books Lean Hospitals and Healthcare Kaizen, as well as The Executive Guide to Healthcare Kaizen. His most recent project is an eBook titled Practicing Lean that benefits the Louise H. Batz Patient Safety Foundation, where Mark is a board member. Mark is also the VP of Improvement & Innovation Services for the technology company KaiNexus.

Posted in: Blog
Tags: ,

29 Comments on "10 Common Problem Solving Mistakes"

Trackback | Comments RSS Feed

  1. Rob Worth
    Twitter:
    says:

    Number 5 is interesting. Just thinking off the top of my head it almost suggests the idea of a “root symptom” (or set of root symptoms). This would be the mirror of the “root cause”.

    So to run with your, “We don’t have enough MRI machines,” example, a “root symptom” might be: patients wait to long to get an MRI scan. Or better: patients wait too long to get a diagnosis.

    Maybe one principle of a root symptom is that it must mention patients or patient care somewhere?

    Is there already this kind of idea out there?

    Rob

    • Bryan says:

      Hi Rob,

      “Is there already this kind of idea out there?”

      Yes, it is called “cause and effect.” The “five why” questioning tool is integrated with cause and effect in the concept of a causal chain. Other similar concepts are “IF-THEN”, etc. Basic logic, engineering, systems thinking kind of stuff.

      Regards,
      Bryan

      • Mark Graban
        Twitter:
        says:

        I think Rob’s question was about the idea that a “root cause” must include the patient perspective somehow. I haven’t heard that used as a rule or guideline for RCA and I’m not sure if that would work. But, we need to not lose sight of the patient needs, quality, and value.

  2. Rob Worth
    Twitter:
    says:

    As a 9a you could also have, “Not removing the possibility of going back to the old ways.”

    Mark Eaton talks about “throwing away the old shoes”. He says that when you buy new shoes they are stiff and uncomfortable and if you keep the old shoes the temptation is to still wear them. But if you throw away the old shoes you will break in the new shoes all the quicker.

    Of course with making improvements you should only throw away the old shoes once you have verified that the new shoes fit, which is part of your number 8.

  3. Rob Worth
    Twitter:
    says:

    If we classify your ten points as to which part of the PDSA cycle they are in you get:

    Plan – 1) Jumping to solutions (before understanding the problem or its root cause)
    Plan – 2) Jumping to the root cause (without thorough enough analysis and observation)
    Plan – 3) Not going to the “gemba” to talk to the people involved and to observe first hand
    Plan – 4) Solving the wrong problem (the real problem isn’t what you think it is)
    Plan – 5) Stating the problem as the lack of something (pre-supposing a countermeasure), such as “problem = we don’t have enough MRI machines” so the obvious countermeasure is “buy another MRI”
    Plan – 6) Thinking of “solutions” instead of “countermeasures”
    Plan – 7) Trying to fix others before fixing problems in your own circle of influence
    Study – 8) Not confirming that countermeasures really led to improvements
    Act – 9) Not confirming that the improvements are sustained over time
    Meta Study (the PDSA of your PDSA) – 10) Not reflecting on the learning that occurred during problem solving (focusing only on the results)

    This points up that there are no faults with the Do (run the experiment) part of the PDSA cycle. So may I suggest the following:

    Do 11) Not running the experiment as described in the plan (typically stopping too early).
    Do 12) Not running an experiment at all – this could also be a variant of (1)
    Do 13) Not running the experiment as an experiment (e.g. subset of work / limited time / one area out of many), but changing everything at once. (Though perhaps is a defect of Plan since that is where you design the experiment…)

    • Mark Graban
      Twitter:
      says:

      Rob – Yes, I sort of grouped them intentionally in that sequence. Thanks for adding the “Do” problems. When I get this down to 9 or 10 or 11 for an article, I’ll include something in the Do category, because people do make mistakes there…

      Thanks for your thoughts and additions.

  4. Dean Bliss Dean Bliss says:

    Good list, Mark. In addition to your list, one of my favorites is “a solution in search of a problem”; in other words, having a pet project or pet experiment that someone has always wanted to do, and looking for an excuse to do it.

  5. Colin
    Twitter:
    says:

    Hello Mark.

    Nice list. #1 & #2 are definitely ones that apply to the HealthIT space. When we hear of a user having an issue with an aspect of our software we start throwing out ideas on how to solve it…often by writing even more code. I’m guilty of this.

    The better approach is to step back and truly understand the problem before crafting a solution or preventative measure. Maybe the user doesn’t really need that button…maybe something needs to be removed instead.

    Looking forward to the article!

  6. Matt Wrye says:

    I think #1 is really important and #5 is something I see a lot and have to coach others in. With all that said, #8 is a huge issue. People put in countermeasures and move on without verifying if the countermeasure worked and if so did it work to the level they predicted it would. In fact, did they even have a hypothesis they were testing?

  7. Bob Emiliani
    Twitter:
    says:

    What about not recognizing problems to begin with? Legendary is the habit of managers to shut-down people who bring problems to them, to ignore problems, or to insist that obvious problems do not exist.

    • Bryan says:

      Hi Bob,

      Great point. Identifying a problem is the first step in problem solving. Unfortunately, many people are stuck in the denial stage as you suggest – and wonder out loud why there are recurring problems in their organization.

      I use the first 3S of 5S to do genba observation exercises – this gives me a great opportunity to practice coaching the basics of problem solving and gives people the opportunity to see that identify problems is an ongoing exercise.

      Regards,
      Bryan

    • Mark Graban
      Twitter:
      says:

      Yes, “no problems is a problem.”

  8. Mark Graban
    Twitter:
    says:

    Via linkedin:

    “Super-duper list…and I like the order too. Maybe the first item might be the inability to recognize that there is a problem at all.”

  9. Bart Sellers says:

    The list could go on with…
    a. neglecting to understand the customer
    b. neglecting to involve the decision maker
    c. scope is too big

  10. Todd LaRocca says:

    Thanks for the list. Problem solving lists never get old. I’d say they’re not referred to enough. I experience #5 and #6 most often in the government sector.

  11. Nice and very recognizable list Mark,

    I’ll give you an additional list of 10 now ;-)
    1. not knowing why the problem is even important
    2. assuming the way work works (related to #3 and resulting in several others on your list)
    3. no clear future state other than in terms of results (but not in terms of principles and conditions to be respected)
    4. lack of focus on the underlying system of work and its problem mechanisms (like it is done in P-M analysis)
    5. seeing conditional and accelerating factors as the root cause
    6. no verification on the genba of the logic used in the “5-why”
    7. seeing a corrective action as a countermeasure
    8. forgetting to standardize an effective countermeasure and integrating it into the system of work
    9. only looking at the problem of occurrence, and forgetting about the problem of non-detection
    10. not differentiating between problems stemming from the absence of a standard, possible non-adherence of standard or when actually adhereing to the standard (and still having the problem).

    I like Rob Worth’s additions on the “Do” phase: many don’t understand it is first and foremost about an experiment (and trying) instead of thinking you know for sure upfront your countermeasure will be effective.

    Kind regards from Holland,
    Rob

    • Rob Worth
      Twitter:
      says:

      Rob,

      Glad you like the Do additions. I relate very much to your 1 and 3. Not having a set of principles to shape a future state means you often drift off in all sorts of directions.

      Could you explain what you mean by “5. seeing conditional and accelerating factors as the root cause”?

      Thanks,

      Rob

  12. Rob,

    It relates to the classical discussion about the victim of a burglary shooting the burglar: is the burglary in itself the root cause? Some will say “otherwise the shooting wouldn’t have happened”. But on the other hand, the burglary in itself is not enough reason to get shot either is it… So what is now the root cause?

    Another analogy could be the catalyst in a chemical reaction. Is the catalyst a root cause of the reaction or just an accelarator or condition?

    It is also well articulated in an approach used in investigating safety incidents, called TripodBeta (used at Shell a.o.). In safety you often look at “last prevention barrier” and events instead of conditions.

    Furthermore, I think P-M analysis used in TPM is also a rigorous approach to finding causes through analysis of the physical phenomenom and the mechanism that created the phenomenom.

    Lastly, I was “raised” in a Lean culture in which we often used reverse logic which implied asking that if you would eliminate the assumed root cause, the observed problem really would not occur anymore. If not, we continued searching.

    Hope this clarifies what I tried to convey.

    Brgds, Rob

  13. Mark Graban
    Twitter:
    says:

    From Mike S. on linkedin:

    “Interesting list, but I think the lack of problem recognition belongs on the list – there’s even a Japanese saying that says to celebrate mistakes (because then the root cause can be found and corrected). Hard to problem solve when the problem is undetected/overlooked/ignored.”

  14. Steve Harper says:

    I love all the comments, but I still find one common mistake missing: assuming there is only one root cause. Many problems are complex and are the result of multiple contributing factors. In aerospace, this is quite often the case, as I would assume would also hold true in the medical field.

    There is also the situation where sometimes it is not possible to prevent a problem with one countermeasure. Thinking “one bullet will kill it” is also a common mistake. This is part of some of the previous comments, but it normally falls under the mentality that “we did something, now we’re done”.

  15. The #1 problem, I think, is believing that you are able to solve the problem. “I know what to do!” is the problem – otherwise, if people were less certain (or if heroics were not rewarded. The person who runs into a burning building and snuffs the flames is a hero – but lucky. The person who steps back, determines what caused the fire, what materials are burning, the best material to extinguish the flame and how to deploy the firefighters will save more lives.) they would approach problems more cautiously, measure results and learn from each step.

    The Shingo model begins with humility. People must believe in their own ignorance, understand that any solution they invoke is only a best guess at a moment in time, and remain keenly aware that each situation is, in some way, its own unique instance.

  16. Nicholas Comeau says:

    #5 on Mark’s list is a big one. To expand further, what happens a lot in companies who are just starting with lean is, problems will be identified as “lack of” a specific lean tool, such as standard work or 5S. People get enamored by the TOOLS and think they will come in and save the day, and never really fully understand what the problem is they are trying to solve, or waste they’re trying to remove (#2 and 3).

  17. Bryan says:

    Re: #6 – Thinking of “solutions” instead of “countermeasures”

    This sort of feels like we are splitting hairs here, or perhaps this is a tomayto-tomahto situation?

    What is the difference in your experience Mark?

    • Mark Graban
      Twitter:
      says:

      I think the words “solution” and “countermeasure” have different connotations to different people.

      I think the intent in using “countermeasure” and discussing the connotations is helpful.

      Solution sounds too permanent. I solved it. We’re done. Fixed it. There’s too much certainty in that word.

      Countermeasure implies an action that may have some positive impact but might be temporary… or might have some side effect or it creates/unearths a different problem.

      So I think it’s more a matter of the mindset than the specific word. But hearing and using the word countermeasure has been helpful for me and my clients. They might still say “solution” but they are talking more about the countermeasure mindset.

  18. John Hunter
    Twitter:
    says:

    My biggest annoyance is just ignoring the problem and just thinking that is the way it is. But the next one is #8, so many solutions don’t solve much :-(

    If #3 and #8 (and #9) are done, lots of the others will happen – eventually (as long as people don’t like failing over and over and they then just go look at how to do PDSA…).

  19. vidyut chandra patange says:

    In an organization , each person is bounded by the status, position, and adequate ego related to it. So i understand the people fallacy on problem resolution are based on facts below:

    -Time bound for resolution of problem…urgency matters most cases.
    -The level of management handling it …(top/middle /bottom)
    -The intuition or understanding of person responsible for handling problem ( His/her past experience on same)
    -The gravity of problem that is linked to the corporate policy /objective..
    -The organization policy matter that binds the particular area of problem..
    Finally the management systems that controls the flow of information or communication within the organization.
    Last but not least, the attitude of person handling the problem.

  20. Arnie Olsen says:

    One problem I don’t see discussed so far is the lack of understanding of the depth of the problem. Problems are easy to find and the solutions are generally simple to find using the right tool-set. However, I have seen many instances of solving one problem only to create three others because the entire value stream isn’t considered.

    Another problem is finding a solution that is scalable. Often times, one problem exists across multiple lines (manuf) and or services and solving the problem that can be used effectively in all of the areas affected is where you make the real money.

    JM2C :)

  21. Daisy Jiang says:

    I think the 1st one is the most prevalent one. A lot of people – myself included – make haste to put a band-aid solution over the symptoms of a problem, without dwelling on what the root cause of the problem is, and then addressing that.

    Thanks for posting!

Post a Comment