The Problem With Problem-Solving

Just this past week, Seamus Maguire publsihed a book entitled Finding Fact Before Fixing: How Business Professionals Can Avoid False Assumptions When Solving Problems, which explores the reasons, biases, and blind spots that result in business professionals making assumptions and jumping to conclusions during problem-solving.

During a recent conversation with Seamus, I asked him: "What are some of the common mistakes business leaders make when problem-solving?" Here is his answer:

It’s my opinion that assumptions, not complexity, are the biggest obstacle to effective problem solving today.

There are a myriad of tools and frameworks that we can follow, from DMAIC to A3 and everything in between. However, even when these tools and frameworks are followed and we have the right people, problem-solving activities can still fall short.

The issue lies not in the tools themselves but rather in how people are hardwired to focus on fast results.

This creates a subconscious tendency to accept our best guesses as facts. We regularly skip the part of an investigation that requires experimental work or going to the gemba to observe.

This tendency is so subtle that we often don’t even realise we are doing it. Often, the potential causes feel so right and are so logical that it seems a waste of time to challenge them through experimentation.

The thing is, we will always be wrong more often than we are right in problem solving, and that’s ok! We can’t think our way out of a problem; if we could, well, it wouldn’t be a problem.

The alternative takes a little more work; it involves creating a way to test our hypothesis so that we learn more about the process/product in question until we reach the point where our knowledge encompasses the problem. At this point, it is no longer a problem.

That’s why true root causes often seem so obvious in hindsight. Until we have the knowledge, the issue is super complex. Then, once we gain the required knowledge, the problem becomes simple and mundane overnight, and you scratch your head, asking why it took so long to figure it out.

So next time you are asking for an update on a problem-solving activity, instead of asking ‘Have you got to root cause yet?’, or, ‘What’s the root cause?’, maybe ask, ‘What have you experimentally ruled out so far?’, or, ‘How did you confirm that?’ This will shift the focus to how problem-solving is conducted, rather than encouraging the team to accept assumptions as fact to achieve a quick result.

What do you think of Seamus's perspective? Do these types of mistakes happen in your organization? What have you done to rectify them? 

Can Lean, Blockchain, and Systems Thinking Be Combined?

Back in June,  Machiel Tesser co-authored and published a book entitled Lean Blockchain Systems Thinking: Reinventing Value Streams with John Dennis. This book shows that blockchain, together with Lean and Systems Thinking, can provide multiple advantages for societies and the environment and can be used effectively to meet sustainable development goals (SDGs).

When I spoke with Machiel in July, I asked him: “What are the benefits of combining Lean, Blockchain, and Systems Thinking?" Here is his complete answer:

Blockchain and Lean: Building the Lean Internet

Blockchain and Lean are a match made for the modern era, creating a Lean Internet. Where Lean empowers us to eliminate waste and streamline value, blockchain goes a step further: it prevents waste before it even arises.

Lean lays out the philosophy and methodology, while blockchain delivers the digital toolkit: digital identities, verifiable credentials, automated rules, workflows, and consensus on standards. This makes processes instantly verifiable, compliant with regulations, and building blocks for an intention economy.

What was once theoretical is now tangible: in the U.S., the GENIUS Act is shaping a robust framework for stablecoin issuance and programmable finance. In the EU, MiCA and eIDAS 2 have come into full force (since December 2024), providing regulatory guardrails for digital assets and trusted digital identities.

Now, blockchain and crypto aren’t speculation or hype; they’re legally programmable and digitally enforceable.

Lean workflows in Real-Time

Workflows become pull-based and real-time, backed by quality proofs from the source, just like Lean Kanban: only what’s needed, when it’s needed. Smart contracts automate verification and trigger actions instantly, eliminating manual or paper processes, reducing errors, carbon emissions, and admin overhead.

Continuous, Network-Wide Improvement

Direct feedback loops and transparency cultivate a shared understanding of the network’s intent. It brings stakeholders onto the same page who are willing to improve the system rather than just their own parts. 

Identifying and solving problems together aligns perfectly with the continuous improvement ethos of Lean. By making performance and objectives visible, stakeholders can respond quickly and collaboratively, making progress proactive rather than reactive.

By targeting root causes, not just symptoms, and listening to every voice across the network, this approach shifts us from reactive fixes to proactive systems design. It’s an inclusive, holistic transformation: the true promise of a Lean, a programmable internet, reinventing value streams.

Do you agree with Machiel's perspective? Has blockchain been integrated into your Lean initiative? If so, what have been the results?

Those Who Facilitate Improvement Workshops... and the Mistakes They Make.

During this past May, Sheilah O'Brien published a very useful and practical book entitled Facilitating Rapid Process Improvement Workshops: The Self-Study Guide for Lean Leaders. The intent of the book is to help professionals who feel they are not truly gaining the full results of improvement initiatives and kaizen events. In the book, Sheilah speaks to the facilitator through coaching notes and actual workshop documents and techniques so the reader can fully understand how greater results are achieved. 

When I spoke with Sheilah last week about her book, I asked her: "What are the common mistakes facilitators make when overseeing rapid process improvement (RPI) workshops?" Here is her complete answer:

The common mistakes of facilitators of RPI workshops are:

1. Not understanding the facilitator role before you start. The RPI team is made up of workers who know about the problem to be analyzed.  They are dedicated. Facilitate with respect and inclusion. By passing on lessons and what you know to the team, you are working your way out of a job. 

• “Team, please look at this flipchart. Do any of you want to change or add to them? Does everyone agree?” 

• The facilitator's role should be to get the exercise started. Once it gets going, the volunteer facilitator (from the team) can carry it to its fruition. 

• The facilitator lets the RPI team have their lead. The team knew what to do next.  

2. Not assuring that there is a monitoring system in place after the RPI ends: 

• The end of the RPI means a shift in roles.  You, as the facilitator, no longer facilitate the workshop. Now you take on an advisory role to the process sponsor and responsible managers on how to track the implementation of improvements.

3. Not knowing that you need to keep two steps ahead of the team:

• The facilitator, proud of the development of an improved process with all its steps, forgets about all the process supports (to those steps) that need to be improved too, such as forms, materials for the job, etc. 

• The facilitator gets midway into the workshop and realizes he/she does not have a mechanism “to pull it all together”-- the risk is the team’s good work can go missing.

4. The facilitator hasn’t considered the “what if’s?”:

• What if the organization doesn’t have data available? 

• What if no one is available to take the team through the workplace (i.e., GEMBA)? 

• What if you discover there is a backlog?  

• What if there are many "products" that come out of the process?  There isn’t time to flowchart them all. 

What do you think about Sheilah's perspective on common mistakes facilitators make? Do you see these same mistakes in your organization? Are there others that are not listed here that you feel are common?

Can Lean Principles Be Applied to the Process Industries?

Peter King just published a second edition of his groundbreaking book Lean for the Process Industries: Dealing with Complexity this past June -- just about 10 years after the first edition was released. Since the publication of the first edition, Peter has been busy consulting with food, beverage, gasoline additive, and nutraceutical companies -- these new experiences have broadened his perspectives on certain Lean processes and have given him a richer set of examples to discuss in this new edition. I spoke with him this month and asked him: “Why do Lean improvement efforts lag within the process industries?” Here is his complete answer:

That is a question that puzzled me for a long time.  During the last 18 years of my DuPont career, while we were having much success applying Lean concepts to process operations, I saw nothing in the literature and heard nothing at conferences about others in similar industries applying Lean.  So, I decided to do a little research.

What I learned is that there was some Lean activity in process operations, but it was not being talked about. Process companies can tend to be very “camera shy” – That is, secretive about their process details and methods.  Because the companies doing very effective Lean work were having success but being relatively quiet about it, it didn’t spread among other process companies due to lack of role models or documented success stories.

The  success stories that were documented were almost all in discrete parts manufacturing and assembly – automobiles, refrigerators, microwave ovens, computer keyboards, etc., which created the feeling among process companies that “I’m different – my processes just don’t look like that.”  Those differences are real, but it doesn’t mean that the Lean philosophies and concepts don’t apply; it just means that you have to think about them in a different context. 

The latter part of my DuPont career was spent doing just that: understanding Lean concepts and tools and then figuring out how to adapt them to improve chemical, food, fiber, and synthetic rubber processes.

A very pertinent example is cellular manufacturing. Many have concluded that this tool, very useful in parts assembly, has no place in process manufacturing because the equipment is generally too large to be relocated to move into a cellular configuration.  But we proved a long time ago that by thinking beyond physical arrangements to understand the real benefits of cells, cells could provide very significant value without any relocation.

After leaving my 42-year DuPont career, I decided to write Lean for the Process Industries to provide documented examples of Lean success in process operations, with guidance on how to adapt the concepts and tools and a clear roadmap on how to meet the challenges.

The positive reaction that book received has led me to believe I met that objective. 

About a year ago, based on the success of the first edition, I was offered the opportunity to write a second edition.  I enthusiastically seized that opportunity.  The first edition had been written largely based on my Lean experiences with various DuPont processes.  In the intervening 10 years, I have consulted with companies covering a much broader array of process operations: transmission and brake fluids, vitamin tablets, biological materials for human implant, salad dressings, puddings, potato chips and others, and have faced new challenges that have broadened my perspectives on how to apply the concepts, all of which are captured in the new edition.

Thus, I feel that the second edition meets the objectives I had for the first edition even more completely and thoroughly, and will reduce the gap referred to in the initial question.

What do you think of Peter King’s viewpoint? Have any readers who have been using the first edition of the book read this new edition? What are your thoughts?

Reactive Improvement and Effective Daily Management

In December, Ross Kennedy published a book entitled Understanding, Measuring, and Improving Daily Management: How to Use Effective Daily Management to Drive Significant Process Improvement . This book explains the critical parts of a continuous improvement strategy to achieve operational excellence and where reactive improvement through effective daily management fits in.

During a recent conversation with Ross, I asked him: “What is reactive improvement and why aren’t more companies embracing it?” Here is his complete answer:

To achieve operational excellence, organizations need a continuous-improvement strategy that includes reactive improvement to ensure you have effective daily management, stable production, or work plan to minimize fire-fighting caused by unplanned changes and proactive Improvement to take you to your improvement vision of world-class performance. Unfortunately, many organizations get so focused on proactive improvement through capital projects or operational excellence initiatives such as Lean, Six Sigma, or Total Productive Maintenance (TPM), that they lose sight of the importance of reactive improvement and having a stable production or work plan.

Reactive improvement develops the capability and discipline within the organization to be able to rapidly recover from an event or incident that stops you from achieving your expected or target performance for the day, shift, or hour and most importantly, your ability to capture the learning and initiate corrective actions so that the event or incident will not re-occur anywhere across the organization.

As such, reactive improvement focuses on improving daily management through your daily review meetings, your information centers supporting the daily review meetings, and your problem-solving root cause analysis capability at all levels, especially at the frontline.There are seven key elements of reactive improvement that must work in concert for effective daily management: 

1. A supportive organization structure to support development of your frontline people so they have ownership and accountability for the performance of their area of responsibility. 
2. Effective frontline leaders to ensure everyone else in the leadership structure are not working down a level. 
3. Appropriate measures with expected targets that are linked to the site’s key success factors for operations to ensure goal alignment and are relevant for the focused areas. 
4. Structured daily review meetings to identify opportunities (problems/incidents) and monitor progress of their solution so they don’t happen again. 
5. Visual information centers that visually display daily and trending performance along with monitoring of actions to address problems/issues raised.
6. Frontline problem-solving root cause analysis capability across the site. 
7. Rapid sharing of learning capability across shifts, departments and the organization. 

What do think of Ross's overview of reactive improvement? Do you practice this technique in your company?

Total Productive Maintenance (TPM) and Lean Maintenance -- What's the Difference?

“What is the difference between Total Productive Maintenance (TPM) and Lean Maintenance?”

That's the question I just posed to Torsten Dederichs, who just published a new book entitled Lean Maintenance: A Practical, Step-By-Step Guide for Increasing Efficiency with Javier Girón Blanco. Considering the amount of money industrial companies spend maintaining their plants and  maintenancing their equipment, I figured it'd be best to include his entire answer here:

What is the difference between onions and apples? Onions are vegetables and apples are fruits.

The first principle of TPM is that the operator is the first line of defense against unplanned downtime. Because operators know their equipment best, they can identify problems long before they get critical. This approach is  a very valuable approach for increasing reliability and reducing  wasted time and repairs.

But what happens when the operators cannot solve the issue themselves? What if the repair needs skilled crafts or engineers? The operator raises a maintenance notification, which launches the maintenance process. And in this same second the operator leaves the TPM world and hands over his engine to our “Lean Maintenance” approach.

Maintenance technicians are the "go-to folks" when machines break down. They are modern-day heroes who can fix anything at anytime. The role of the “hero” becomes evident when maintenance starts to work in a predominantly reactive mode, fire-fighting its way through the day. At this point,  employees begin to view maintenance as a necessary evil because it is basically a cost center that requires management attention as well as capital (spare parts inventory) and personnel. This sentiment is exacerbated when maintenance is performed “at all costs” -- work orders take more time, money and effort to get done, budgets are exceeded, and an unhealthy relationship develops between maintenance and production. At this point, upper management starts to consider ways to get costs under control: top-down cost reductions (meaning that less maintenance gets done, with the corresponding availability risk) and partial or total outsourcing. These measures can provide a quick fix but will not resolve the firefighting nor fix the broken relationship between maintenance and production. This situation can lead to frustration, as things go back to where they were before. To break this vicious circle we propose a different approach.

Maintenance can be a source of profitability by ensuring high availability. As mentioned previously, companies with an efficient and effective maintenance function have a clear competitive advantage. A Lean maintenance function ensures that all resources are dedicated to value-adding activities, taking out the process “waste,” and being able to do more with the current resources.

To achieve Lean maintenance, many elements must be in place: the interfaces between production and maintenance along the full maintenance process must be smooth and maintenance work must be properly selected, prioritized, planned, scheduled and carried out. Everyone involved in the process should know how he or she can contribute to this goal.

The description of the ideal maintenance process and the method for achieving it is the focus of Lean Maintenance: A Practical, Step-By-Step Guide for Increasing Efficiency.


What do you consider the differences between TPM and Lean maintenance? Have you practiced Lean maintenance in your company?  

Process Problems -- Just Five Types?

I recently spoke with Kicab Castaneda-Mendez, who recently published a book titled What's Your Problem? Identifying and Solving the Five Types of Process Problems, about root cause analysis and his definitions of process problems. I asked him specifically: "How is reducing process problems to just five types a breakthrough in process improvement? What are the key benefits?" Here is his complete response:

Typically, root cause analysis is taught by explaining a variety of tools that requires users to gain considerable experience before being able to apply them correctly in the proper settings. To provide practice, tools are often taught without context which results in users not knowing when to apply them. A third common condition is when problem solving is taught as a sequence of expansions and contractions, specifically in finding root causes and solutions.

By reducing all process problems to just five types based on the cause, we eliminate the need to search for what the cause is. Since these specific causes can be addressed in time-proven ways, the search for solutions is also reduced. The result is that we can significantly simply process problem methodologies to a three-step procedure:

• Identify the type of problem,
• Find the root cause (where it occurs -- we know what it is), and
• Address the root cause.

We benefit in several key areas: vastly simplified teaching, learning, applying, and mentoring. Because virtually every adult has solved these types of problems using the proven techniques, we can easily create lessons that build on this knowledge without burdensome language. With training time reduced by as much 50% to 80%, students can go through multiple cycles of practice on the three-step procedure on all problem types versus at most one cycle of other methodologies on one problem.

Isn’t that what process improvement is all about: increasing quality while reducing costs and time?

What do you think Kicab's methodology? Do you think all process problems can be reduced to just five types?