The PDSA cycle (Plan, Do, Study, Adjust) is at the heart of Lean problem solving. Most of these mistakes cluster in the Plan phase, where the temptation to skip ahead is strongest. A few live in Study and Adjust, where follow-through breaks down.
I first shared this list in 2012 to get reader reactions before fleshing it out. Dozens of comments later, I've updated it with examples from healthcare, manufacturing, and my own experience.
Plan: Jumping to Solutions
This is the single most common problem-solving mistake. Someone describes a problem, and within 60 seconds the room is brainstorming solutions. The pressure to act feels productive, but you end up fixing symptoms while the root cause stays untouched. I wrote a separate post about why jumping to solutions is such a hard habit to break — especially for experienced leaders who've been rewarded for decisiveness their entire careers.
Plan: Jumping to the Root Cause
The mirror image of jumping to solutions. Instead of skipping the cause, you land on one too quickly — before you've observed the work, talked to the people involved, or gathered enough data to know whether your assumed cause is real. I've seen teams spend weeks implementing a countermeasure for a root cause that turned out to be wrong because nobody went to the gemba to check.
Plan: Not Going to the Gemba
You can't solve a problem from a conference room. Going to the gemba — the place where the work actually happens — means talking to the people involved and observing firsthand. When I visited Toyota plants, the emphasis on “go and see” wasn't a suggestion. It was non-negotiable. Problems look different up close than they do in a report or a dashboard.
Plan: Solving the Wrong Problem
Sometimes the real problem isn't what you think it is. A hospital might define the problem as “we don't have enough beds” when the real problem is that discharge processes take too long and patients who are ready to leave are still occupying beds. The problem statement shapes everything that follows. Get it wrong and the best problem-solving process in the world will produce the wrong answer.
Plan: Stating the Problem as the Lack of a Solution
This is a subtle one. “The problem is we don't have enough MRI machines” presupposes that the countermeasure is buying another MRI. A better problem statement might be: “Patients are waiting too long for MRI scans.” That opens up a wider range of causes and countermeasures — scheduling, preparation time, scan protocols, equipment uptime — instead of jumping straight to a capital purchase.
Plan: Thinking “Solutions” Instead of “Countermeasures”
The word matters. A “solution” implies finality — the problem is solved, move on. A “countermeasure” implies something we're testing to see if it works, with the expectation that we'll study the results and adjust. The language keeps us in a learning mindset instead of a “fixed it” mindset.
Plan: Trying to Fix Others Before Fixing Your Own Area
It's always easier to see waste and problems in someone else's department. But effective problem solving starts within your own circle of influence. Fix what you can control first. That builds credibility and trust — which you'll need if the problem eventually requires collaboration across boundaries.
Study: Not Confirming the Countermeasure Worked
You tested a change. Did it actually improve things? A surprising number of teams implement a countermeasure and declare victory without checking the data. The “Study” in PDSA exists for exactly this reason — to verify that what you did actually produced the result you expected. Process Behavior Charts are one practical way to see whether a change produced a real signal or just noise.
Adjust: Not Confirming Improvements Are Sustained
Even when a countermeasure works initially, it can fade over time. People revert to old habits. Conditions change. New staff arrive without the context. Sustaining an improvement requires ongoing attention — auditing the process, refreshing the standard work, and making sure the gains don't quietly erode. This is where Leader Standard Work plays a role.
Meta-Study: Not Reflecting on What You Learned
The last mistake is the most overlooked. After the problem is solved (or addressed), did you reflect on the problem-solving process itself? What went well? What would you do differently? Toyota calls this hansei — reflection. It's the PDSA of your PDSA. Skipping this step means you get better at solving individual problems but never get better at problem solving as a practice.
Frequently Asked Questions
Jumping to solutions. Most teams start brainstorming fixes before they've fully understood the problem, observed the work firsthand, or identified the root cause. In Lean problem solving, the Plan phase — understanding the problem and its causes — should take the majority of the effort. Most organizations spend too little time here and too much time implementing changes that don't address the real issue.
PDSA stands for Plan, Do, Study, Adjust (sometimes called PDCA, with “Check” instead of “Study”). It's a structured approach to problem solving and improvement that originated with Walter Shewhart and was popularized by W. Edwards Deming. The key discipline is treating every change as a test — studying whether it actually worked before standardizing it or adjusting course.
A solution implies finality — the problem is solved. A countermeasure implies a test — something you're trying because you believe it will help, with the expectation that you'll verify the results. Lean practitioners prefer “countermeasure” because it keeps the team in a learning mindset and avoids premature declarations of success.
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
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
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.
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.
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…)
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.
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.
Yes, Dean. Great point.
We can’t (or shouldn’t) “work backward” from a pre-determined solution to a problem statement or a root cause…
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!
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?
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.
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
Yes, “no problems is a problem.”
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.”
The list could go on with…
a. neglecting to understand the customer
b. neglecting to involve the decision maker
c. scope is too big
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.
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,
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
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
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.”
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”.
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.
#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).
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?
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.
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…).
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.
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 :)
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!