Daily Management for Improvement

I’m digging through old archives again, and came across this graphic I put together around 2006 or so. It depicts more detailed version of “Organize, Standardize, Stabilize, Optimize” showing the continuous comparison between “what should be happening” and “what is actually happening.” It is the gap between these two that drives improvement forward.

Like the pocket card in the last post, this is built on a foundation established by the work of Steven Spear, especially his PhD dissertation that is summarized in Decoding the DNA of the Toyota Production System. By the way, if you are in the business of continuous improvement, reading (and understanding) this breakthrough work is critical for you.

Other than generally sharing this, my other reason for putting this up is that in the Toyota Kata community there has been discussion for about a decade about whether or not the right hand loop – pushing for stability – is an appropriate use of the Improvement Kata.

I think that is an unfortunate result of some very early conversations about the difference between “troubleshooting” and “improving” a process. We get into semantic arguments about “problem solving” as somehow different from “root cause analysis” and how the Improvement Kata is somehow distinct, again, from those activities.

This makes no sense to me for a couple of reasons.

Scientific Thinking is the Foundation

Toyota Kata is not a problem solving tool. It is a teaching method for teaching scientific thinking, and it is a teaching method for learning to teach scientific thinking. In the books and most literature, it uses organizational processes as working examples for the “starter kata,” but exactly the same thinking structure works for such diverse things as working through quality issues, developing entirely new products and processes, working through leadership and people issues. The underlying sub-structures may change, but the basic steps are the same.

When I encounter an organization that already has a “standard problem solving approach” I do not attempt to tell them they are wrong or confuse them by introducing a different structure. Rather, I adapt the Improvement and Coaching Kata to align with their existing jargon and language, and help them learn to go deeper and more thoroughly into their existing process.

Stability is a Target Condition

I see a lot of pushback about working to “return a process to standard.” In reality, that is the bulk of the activity in day-to-day improvement. The whole point of having a standard in the first place is to be able to see when the actual process or result is somehow different.

Think about it: If there isn’t an active means of comparing “actual” vs. “standard” what is the point of having a standard in the first place?

Think of the standard as a target condtion.

What obstacles are preventing you from [operating to that standard]? You can guess, but the best way is to diligently try to operate to the target condition and see what gets in your way. That might not happen immediately. Maybe some time will go by, then BAM! You get a surprise.

This is good. You have learned. Something you didn’t expect has interfered with getting things done the way you wanted to. Time to dig in and learn what happened.

Maybe there was some condition that you could have detected earlier and gotten out in front of. Who knows?

This is all part of the continuum of Troubleshooting by Defining Standards.

You Cannot Meet a Challenge Without Working on Stability

As you are working to reach new level of performance – working toward a new challenge – there will be a point when the process works sometimes, so you know it is possible. But it doesn’t work every time because there are still intermittent obstacles that get in the way.

Nevertheless, you have to work diligently to see problems as they occur, respond to them, dig into causes (root cause analysis anyone?) and systematically protect your process from those issues.

The only real difference between covering this territory for the first time vs. trying to recover a previously stable process is that in the later case you can ask “What has changed?”

But, in the end, in both cases – stabilizing a new process vs. re-stabilizing an old one – you are dealing with conditions that are changing from one run to the next. That is why it works sometimes and not others. You don’t know what is changing. You are trying to figure it out by experimenting and learning.

What About Root Cause Analysis?

My challenge is still a stable process.

My current condition is my level of understanding of how the process works today, and the exact mechanism that results in a defect. Even defects are produced by a process – just not the process we want.

That understanding will be incomplete by definition – because if we truly understood what was going on we wouldn’t have the problem. So… what do I know (and can prove with evidence) and what do I not know.

What do I suspect? What evidence do I need to gather to rule out this possible cause, or keep it in play? Next experiment. What do I expect to learn?

I’ll write a more detailed post about this at some point. I think it is a topic worth digging into. Suffice it to say that I have absolutely used the Improvement Kata structure to coach people through finding the root cause of wicked quality problems.

It really helped that they were able to see the same underlying pattern that I had already been teaching them. It made things simpler.

Don’t Complicate a Simple Concept

It’s all “solving problems” (the term “problem solving” apparently has some specific form it needs to take for some people).

The underlying structure for all of it is scientific thinking. Some say it’s PDCA / PDSA. Same thing.

Splitting semantic hairs and saying “this is different” makes simple things complicated. Yes, there are advanced tools that you use when things get tough. But… addition and subtraction; basic algebra; advanced polynomials; basic differential calculus; advanced multivariate calculus – IT IS ALL MATH. You apply the math you must to model and solve the problem at hand.

DON’T apply more math than you need just because you can. That serves no purpose except, perhaps, to prove how smart you are… to nobody in particular.

Solving problems is the same. There are some cases where I need to develop a designed experiment to better understand the current condition – the interactions between variables. There are cases where other statistical tools are needed. Use them when you must, but not just because you can.

Use the simplest method that works.