Here’s a great post from Pascal Dennis on Lean and PDCA (or PDSA):
Everybody should read Pascal’s post… twice. Honestly, go read it a few times before returning here.
I was fortunate to take an LEI class with him about five years ago. I’ve learned a lot from Pascal’s books.
I was also very fortunate to work with him a bit in person…and I learned so much about problem solving from Pascal and his former Toyota colleagues.
Pascal is what I call “the real deal,” in that he worked for Toyota (in Canada) for many years. Pascal doesn’t make Lean (the Toyota Production System) into some sort of complicated, mythical beast with lots of jargon… he humbly teaches people how to solve problems and how to improve.
A big part of solving problems is learning how to properly DEFINE problems. I am grateful to Pascal and his firm for what I learned and what was reinforced by them… asking, as John Shook (also from Toyota) recently reminded us, “what is the problem we are trying to solve?” Also, how do we really know it is a problem? What is the gap between “what should be happening” and “what’s really happening?”
It takes discipline and humility to really study a problem instead of jumping to conclusions or jumping to solutions. It takes humility to “go and see” and actually talk to the people doing the work instead of assuming you know the answers because of your job title and leadership position.
As Pascal writes about, I’ve also heard people pish-posh at Lean and PDCA (or PDSA) as being too simple. I’ve found that the people who are newest to Lean are the ones who are most certain they understand everything. I’ve been studying and practicing Lean for 20 years… and as Pascal’s sensei said, I feel like I’m barely understanding it… and that’s why I find this a fascinating field to hopefully continue to study and practice for another 20 years or more.
Those who are new to Lean… they might have read one book or taken one class (or received one “belt” through a Lean Sigma program)… these are the folks who think Lean is just a bunch of neat tricks and techniques. I try to be patient and empathetic because I was like that once too.
We are taught a tool… we want to implement the tool. We’re sometimes oblivious that the people in the workplace are annoyed with us for pushing tools on them or changing things without their input. As engineer, I was taught to have “the answer” instead of being comfortable in the murky fog of a change process…
Then, we learn how to teach the tool… understanding what problems need solved and how to engage others in the process. You’re teaching it and inspiring change instead of doing it yourself.
Then, perhaps, we learn to teach others how to teach the philosophies and mindsets behind the tool.
Is this a natural progression or can people jump right to understanding principles, mindsets, and philosophies? I’ve tried teaching, through my books and articles, this blog, and tweets (and classes and speeches) that Lean is really about a mindset and a philosophy… that it’s about Respect for People at its core. Yet, not everybody understands that. We see lots of “L.A.M.E.” and, thankfully, some “Real Lean” as Bob Emiliani calls it.
There are organizations out there, like ThedaCare, doing this right. There are other organizations that drive people to send me emails complaining (rightfully so) that the so-called “Lean” efforts are leading to layoffs, are forcing changes on people, or are hurting patient care. None of that is really Lean… but people call it that.
As David Mann said once, “It’s not that Lean is complicated… but it’s very different.” Can we help folks understand or do they have to learn through their own mistakes?
Image copyright Lean Pathways
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.