Using Control Chart to Understand Free Throw Shooting Results

comment on: Is Andre Drummond Sustaining His Free Throw Improvements?

Nice use of data to understand the system results (and if there is a measurable improvement or not). I still want to see these chronically poor free throw shooters use the pretty clearly better underhand free throw style. I wrote about this previously in Why Do People Fail to Adopt Better Management Methods?

It really is remarkable how much effort is put into so many aspects of gaining small advantages yet a fairly obvious big advantage (underhand free throws continues to be ignored).

Related: Lessons for Managers from the Wisconsin and Duke Basketball Programs - Change Management - Post Change Evaluation and Action - Taking Risks Based on Evidence

Iterate the PDSA Cycle Quickly to Speed Up Learning and Improvement

As you say learning is central to using the PDSA cycle. Those organizations that are most successful turn the PDSA cycle quickly and iterate. A significant part of such behavior is to intentionally design the PDSA to iterate quickly - break down PDSA cycles into smaller pieces that can quickly be iterated.

Comment on: What it Means to Turn the PDCA Cycle One More Time

Related: How To Create a Continual Improvement Culture - Using the PDSA cycle to improve management

Iterate to Continually Improve

Thoughts on: The Challenge of PDSA: Feeling Like You’ve Fallen Short

For me, this snowball was the understanding of the continuous improvement cycle, the iterative process towards ideal state or what many call “true north.” I have seen and explained the well-known visual many times; the person climbing up towards target state and, ultimately, ideal state through PDSA, only seeing ahead of them as far as the flashlight reaches.

The relationship of PDSA iterations and ideal state never really dawned on me while I was working through PDSA cycles in problem solving. The visual depicts the learner stair-stepping up through PDSA cycles, each step up the flashlight seeing further, learning more and getting closer to ideal.
...
In absence of a clearly defined Target state, satisfaction with progress, pace, and incremental improvements may more times than not, leave you feeling as if you have fallen short.

Iteration and continual improvement are key. Understanding that "target state" is a temporary target is important. If a "ideal state" is too specific it can hamper innovation. This usually isn't so critical on fairly short term PDSA (except in those cases when we should look at innovation instead of improving the current process).

The PDSA process doesn't hamper innovation. But, when people set in their minds ideal states or targets that they move toward and don't see those as flexible based on new learning they can stunt innovation.

Related post: Resources for Using the PDSA Cycle to Improve Results - Continually Improving Using a Focus on Delighting Customers

Should I be in the Check Phase of PDCA Daily?

Below is my response on closed forum about whether doing the "check" phase of PDCA daily was too often. I expanded on my comments there a bit in this post.

The check/study phase should be reviewing the results of the experiment done in the Do the experiment phase. "Checking" how things are going during the experiment makes sense but that isn't the check/study phase of PDSA .

For example, you don't want to pay no attention during the experiment and then look at the data and discover the data shows obvious signs the operational definitions were not clear, or the process is providing very bad results. So you need to have those doing the experiment paying attention daily.

Remember one key to using the PDSA cycle is to turn through the whole cycle quickly. Daily would be exceptionally quick. Moving through the whole cycle in 2-6 weeks is more normal. Organizations successful using PDSA will quickly turn the cycle 4+ times for a specific effort (often the 2nd, 3rd... times through are much faster than the first time through).

More on how to use the PDSA well:

• Resources for Using the PDSA Cycle to Improve Results
• The Improvement Guide is a book anyone using PDSA should read and consult frequently as a resource (blog post on the book)
• Keys to the Effective Use of the PDSA Improvement Cycle

Deming Wanted Managers to Understand the Systems They Managed and to Visit Where the Work was Done

Comments on Deming wasn’t a fan of Management by Walking Around

Deming’s view is entrenched in Lean management practice in the form of “Genchi Genbutsu”, literally “go and see” at the “real place”. Where practitioners of Management by Walking Around merely visit the workers for a chat, practitioners of Genchi Genbutsu stay with the workers to understanding what is going on.

True, and the details you provide are important. It wasn't managers going to the gemba Deming was against. What mattered is the system. Some people did Management by Walking Around (MBWA), even decades ago, in a useful way - with understanding. But most did not.

Gemba walks are much more likely to be useful (because the expectations are for a more engaged leader) but there are plenty of times those are not done well, and are no better than bad MBWA. Jim Womack has a book out on Gemba Walks which provides good details to managers on what they should do (and what Deming wanted them to do).

Related: Out of Touch Executives Damage Companies, Go to the Gemba - Leadership and Management - Jeff Bezos Spends a Week Working in Amazon’s Kentucky Distribution Center (2009) - Customer Gemba

Pilot on a Small Scale First - Good Advice We Often Ignore

Response to: Pink NFL Penalty Flags Surprisingly Cause Confusion

This is an example of why piloting new ideas is wise. The truth is we often don't pilot stuff. Many times it works out fine (and no-one mentions we didn't pilot it on a small scale). When you don't pilot and it then fails on a big scale this is the question, I think.

Were we bozos for not seeing the risk - looking back is it a pretty strong case we should have piloted.

If we often don't pilot and it works 99 times out of 100 it may be we are pretty good at knowing what needs to be piloted and excepting some failures is ok in order to get things done. Part of the decision that is critical is making sure you don't fail to pilot when it is really costly to be wrong (which is part of the decision on whether to pilot).

We can just always point to failure to pilot as the dumb thing to do when it fails. But I see that as a bit overly simplistic. Many organization don't pilot well. Getting them to do so all the time would likely stop you from doing better stuff. Getting them to do so when

1. there are likely to be be things we should learn
2. there are significant questions about how it would work
3. the costs of widespread failure are large
4. we can't consider the potential risks and make a judgement that there is likely not to be a problem

Piloting on a small scale is best. It is what I recommend and encourage. I just think seeing the failure to pilot as a cause of the widespread problem is too simplistic. Why did we fail to pilot needs to be the next question - don't stop at the failure to pilot as the root cause. From there you will nearly always discover, unless maybe you are Toyota or the Kaizen Institute or something :-) that your organization consistently fails to pilot before adopting on a wide scale. Then you need to dive into that issue...

With this particular example it seems to me one that could have been thought about rationally and a decent case that we don't need to pilot could have been made. And that illustrates that there is always a risk to implementing without piloting (there is a risk of doing it anyway including a very big one of failing to catch the problems because your pilot failed to capture some important features (for example - you didn't think of the need to pilot with pink towels... - this would be an easy mistake to make).

And it shows why thinking about pilots is important - which is another thing we often fail to do, considering how to make the pilot cover the risky scenarios that may take place. Sometimes organizations will use certain locations to pilot stuff which can be useful - you can train these locations to provide good feedback, etc.. But as soon as you make the pilot locations different than were it will be done there are risks of not catching things.

It is the interaction of variables that often creates problems which it was this time. Pink flags meet the initial criteria of being noticeable. The interaction of putting many other pink items into play (certain jerseys, towels, etc.) is what seems to be the issue.

Related: What is the Explanation Going to be if This Attempt Fails? - Accept Taking Risks, Don’t Blithely Accept Failure Though - Management is Prediction - Combinatorial Testing for Software - European Blackout: Human Error-Not

Early "Lean" Thinking

"There are some who criticize the 'early days' of the Lean movement as being too focused on tools. But, I’ve re-read a lot of the early material and this is not the case." - Mark Graban

Exactly right. It seems to me it was when the first "lean manufacturing" fad wave hit and you had lots of people (that didn't study and learn what it was really about) quickly churn out their oversimplified "lean manufacturing" cookbook tool approach. That is when the tool approach took off and because it is easy to train people on tools that has always been a popular way to sell services to companies. It is really just putting new tools into the existing management system instead of adopting new management thinking which is what the people that actually studied "lean" were doing and talking about. The tools can be helpful but it is a very limited approach to "lean" (if you can even call it that - really it should be called using a couple of lean manufacturing management tools). The initial people who studied Toyota, and other companies in Japan (mainly), understood it was a different way to manage - not just using a couple of tools.

But it was hard to figure out how to actually do it (getting management to improve is hard - it is easy to sell management some training that will "make workers better"). It was easy to offer training in setting up QC circles and how to use various tools, so much of that happened. The biggest change in the selling lean training is you no longer see people selling QC circle training, they now sell other tools.

Here are some early reports (so early it preceded the lean terms widespread use). It also means the focus hasn't already been set by the Machine that Changed the World but it is the same stuff that those that studied in 1980, 1990, 2000 or 2013 saw - it is more about respect for people and using everyone's brain than any specific tool. And these articles have a bit more focus on using statistics and data than much of lean literature today (partially because George Box and Dad were statisticians and partially, in my opinion, because current lean literature is light on using data).

Peter Scholtes report on first trip to Japan, 1986

Managing Our Way to Economic Success: Two Untapped Resources - potential information and employee creativity by William G. Hunter, 1986

How to Apply Japanese Company-Wide Quality Control in Other Countries by Kaoru Ishikawa. (November 1986).

Eliminating Complexity from Work: Improving Productivity by Enhancing Quality by F. Timothy Fuller, 1986

On Quality Practice in Japan by George Box, Raghu Kackar, Vijay Nair, Madhav Phadke, Anne Shoemaker, and C.F. Jeff Wu. (December 1987).

The early lean stuff was much like what is discussed there (though these were before the "lean" term had taken hold). These were all first published as reports at the University of Wisconsin - Madison Center for Quality and Productivity Improvement founded by my father and George Box.

While the format of the documents may be a bit annoying thankfully they are actually available, unlike so many articles supposedly meant to stimulate better management practices (look at major "associations" that don't even make articles available online without a blocking paywall preventing the articles from doing much good).

Related: Management Improvement History (2004 post) - Early History Of Management Improvement Online (2007) - Transforming With Lean (2007) "Successful management improvement is not about mindlessly applying quality/lean tools." - "The tools are very helpful but the change in mindset is critical. Without the change in the way business is viewed the tools may be able to help but often can prove of limited value." (2006) - Lean Thinking and Management (2006) - From lean tools to lean management by Jim Womack, 2006 - I would link to the original article but it is gone :-(

Apply Management Improvement Principles to Your Situation

Can’t Always Believe Somebody Saying “Toyota Would Tell You To...”

We’re not literally hanging “andon cords” or putting tape around every piece of equipment just because a factory does it. We have to be solving hospital problems and not just copying tools. I get that...
There’s going to be variation in healthcare and we have to plan for that and make sure patient care comes first. We need to have a reaction plan for how to try to get back on schedule (and part of that approach could be to have buffer times for charting during the day instead of doing all of the charting at the end of the day).

Well said. Don't surgeons use something equivalent to "tape to make visible if the right tools are ready"? It sure seems like something like that would be wise to me.

The whole idea is to take principles first (and then tools) that are helpful and apply them to your situation/system. The business type will affect decisions (likely software businesses or hospitals will be more similar to those in their industry than others due to some features of that that of business) as will your specific organization.

If you design a system to have much more cross training of people then it will allow you to take advantage of that compared to another organization that instead focused more on specialization.

The decisions you make about individual aspects of the management system will impact what options are sensible for you in any particular instance. It is helpful to challenge yourself by thinking what would others do with this type of dilema but it is helpful not in letting you copy something they do but rather to provide you a new perspective.

Related: Curious Cat Management blog posts on health care - Curious Cat management blog posts on quality tools

Informal, Subconscious PDSA Experimentation

"Informal" PDSA is basically how babies and kids learn.  They don't formalize the theory they are testing but their brain is doing it for them.  If they touch the hot stove they learn hey touching that hurts.  Most brains figure out hot feeling gets super hot if I touch what appears to be the source (even without a helicopter parent telling them).  I don't want to be hurt again.  Don't touch that hot thing.  A bit old they connect the stove place as likely to be hot...  Sometimes they are a bit lame and they fail to make the connections until they get burned a couple times.

Same thing with say putting food into their mouth.  They try various ways of doing so with various levels of success.  Eventually they find good ones.  As kids get a bit older they have to modify the most effective ways of getting food to their mouth to make sure the big huge person sitting next to them doesn't stop them (factoring in "manners" as part of what is needed not just efficiency).

Kids really are amazing at doing "informal PDSA."  But their are ways to get even better by realizing what you are testing consciously.  Especially as systems get complex relying on your brain decoding everything behind the scenes (doing its own subconscious pdsa) gets less reliable.

Response to: PDCA – So Simple, It’s Child’s Play

Related: Encouraging Curiosity in Kids - Experience Teaches Nothing Without Theory - Keys to the Effective Use of the PDSA Improvement Cycle

Quick Mistake Proofing Ideas for Preventing Date Entry Error

I found a new failure mode for online bill pay. I had an electric bill due April 24. I mistakenly entered May 23 as the pay date 

So, by April 30, I had a late payment termination notice from the electric company. Kudos to them for the fast cycle time on getting those out. I paid the bill via credit card on their website. 

I’m not sure how to error proof “wrong date.” You?

It is easy to put in a filter that checks and then puts a big flash message:

  “The date you entered is after the due date. Are you sure you don’t want to put in a date prior to that...”

You can also make the data entry bias toward a on-time payment: require an extra step to go beyond the due date, default the value to be the due date... How you implement this would depend on the entry method.

It is really easy to do well if you are using calendar point and click – grey out all the post due date entries, if click on a greyed out entry, pop-up a message that says “that date is after the due date are you sure...” It gets less effective/cool if it is just text entry...

Even with text entry thought you can popup the message on submit of the form if the date is too late (so they enter the wrong date but you catch it before the action is completed).

You can also follow up with (using this method alone is better than nothing but it is pretty lame so I wouldn’t suggest it as the only method unless nothing else can be done reasonably) email saying “you entered a date after the due date in your last bill payment, if you don’t pay before that late fee…

Anyone what to hire me for a few minutes at a time to think of ways to make it harder to make an error just let me know. I don’t like processes that allow errors so have become fairly good and thinking up ways to make it harder pretty quickly :-)

Related: Mistake Proofing Deployment of Software Code - Improving Software Development with Automated Tests - Poka-Yoke Assembly

Experimenting to Discover

Causal Reasoning in Science: Don’t Dismiss Correlations (the broken link was removed)

Box, Hunter, and Hunter were/are theorists, in the sense that they don’t do experiments (or even collect data) themselves.
...
Science is about increasing certainty — about learning. You can learn from any observation, as distasteful as that may be to evidence snobs. By saying that experiments are “necessary” to find out something, Box et al. said the opposite of you can learn from any observation.

William Hunter was my father. He did many experiments. George Box did many experiments. You are entitled to your opinions obviously but the claim that they only dealt with other people's data is not accurate. It is true they were world renowned experts on experimenting and had many people consult them about their experiments, for help: designing them, analyzing them, what to do next, how to improve the process of experimentation in their organization, etc.. While it seems to be implied in the post that such consultation was a reason to distrust their thoughts on experimentation I hardly think that is a sensible conclusion to draw. Most of those they helped were running experiments in industry, to improve results (not to publish papers).

They were, and are, applied statisticians (and though I am obviously biased, I think many would agree, 2 of the most accomplished in that field in the 20th century). What experiments need to be done is critical for an applied statistician. What matters is making improvement in real world processes. If you don't run the right experiments, you won't learn things to help you improve.

They worked on the problem of where to focus, in order to learn, quite a bit. One significant part of there belief was to have those involved in the work do the thinking about what needed to be improved. This isn't tremendously radical today but in the past you had many people that thought "workers" should do what the college graduates in their office at headquarters tell them to do. Here is one of many such example, from Managing Our Way to Economic Success by William Hunter:

The key is that employees at all levels must have appropriate technical tools so that they can do the following things:

- recognize when a problem has arisen or an opportunity for improvement exists,
- collect relevant data,
- analyze the situation,
- determine whose responsibility it is to take further action,
- solve the problem or refer it to someone more appropriate...

I don't have the book in front of me, but doesn't it start with an example on learning where you can use inductive reasoning and from the facts that you see you can draw conclusions and construct a theory that fits the facts. If so, it seems to call into question the idea that they claimed "[the] opposite of you can learn from any observation." is not actually accurate. They understood you can use inductive reasoning to create theories. You then use experiments to test theories.

The books is called Statistics for Experimenters, right? Not statistics for drawing conclusions when not doing experiments. When you are experimenting you can test whether beliefs you have are accurate and you can learn about things you try. Smart people can make guesses what will happen and be right. I know the authors would believe those knowledgable about the system in question are well suited to determine what variables to test. It is that knowledge that will lead to experiments that are likely to be effective.

The authors of the book were trying to help those that often failed to learn as much from experiments as they could. Far too many people still don't use the most effective statistical tools when experimenting.

They emphasized, consistently, the need for those doing the work to involved in the experiments. The job of statisticians was to help in the cases where advanced statistical tools and knowledge would be useful. The reason for those who do the work (are familiar with the process) is because they have knowledge to bring to what should be tried in experiments.

When I read through The Scientific Context of Quality Improvement, 1987 by George Box and Soren Bisgaard it seems to me it discusses the types of issues you raise: how do we learn without experimenting? I am not sure if it is just me, or if it clearly addresses that issue. Here is another, Statistics as a Catalyst to Learning by Scientific Method by George E. P. Box. And another, Statistics for Discovery.

There are many other sources, I am sure. They understood the importance of learning as much as you could from available sources. They just also understood the importance of experiments and learning the most you could from experiments. And the book, Statistics for Experimenters, was focused on the most effective ways to improve using statistics to learn from experiments..

Here is what Box, said in his own words about the objective (and it isn't proving the hypothesis):

[too many people ]"can’t really get the fact that it’s not about proving a theorem, it’s about being curious about things. There aren’t enough people who will apply [DOE] as a way of finding things out"

Statistics for Experimenters: Design, Innovation, and Discovery shows that the goal of design of experiments is to learn and refine your experiment based on the knowledge you gain and experiment again. It is a process of discovery. That discovery is useful when it allows you to make improvement in real world outcomes. That is the objective.

Should We Set a Goal for the Number of Kaizen Events

Does Setting a Goal for Number of Kaizens Violate "Kaizen Spirit"?

is it reasonable to set a target or goal for the # of kaizen ideas submitted and implemented?
is a goal sometimes necessary to get the ball rolling?
are goals and targets almost always dysfunctional?

I don't see any value in setting goals for the number of kaizen events. It is typical MBA spreadsheet management thinking that has really no value in this instance. There are some times MBA spreadsheet management has limited, but actual, value (many alternatives would be better - but they still have some value).

Goals can be useful to set the scope of solution you are aiming for but in general are a bad idea. This example would be a horrible one, because fixating on the number of kaizen events is silly. No value, only loss - that isn't the prescription for a wise management choice.

Focusing on number of kaizen events seems likely to drive the counterproductive behavior.

should we merely "substitute leadership" as Dr. Deming suggested?
how do we foster intrinsic motivation for kaizen?

This is hard. It involves large scale, deep cultural and management changes. Read the posts from Lean Daily, and the great management books and adopt ideas you learn...

I think this quote summarizes the reality behind setting arbitrary numerical kaizen targets. "managers will try anything easy that doesn’t work before they will try anything hard that does work" - Jim Womack

Does a Good Lean System Need Six Sigma

With a good Lean system in place, do we still need Six Sigma? (the broken link was removed)

There is no Lean Team, but everyone in the organization thinks Lean. Employee satisfaction surveys show steady growth in satisfaction; profitability is increasing; cost are decreasing; less work pressure... The one problem still exist is ensuring JIT delivery from the suppliers network.

Can Six Sigma help the organization to accelerate or further improve this situation?

Good six sigma efforts (even 15 years ago) and lean share many of the same tools and principles that come from earlier TQM and such like efforts. There are some tools that are primarily associated with six sigma (like design of experiments). But those tools far precede "six sigma" even in their application in business. And those tools could certainly be useful in most lean organizations. There is no reason they couldn't just adopt those management tools.

Given that just in time was developed and made popular by Toyota and Deming long before the term six sigma was coined it certainly can be done expertly without six sigma tools. Six sigma tools can certainly help in my opinion, though.

I wouldn't weigh the benefit of any tools or methods or principles based on what category people places them in but instead I would build a management system based on the need of the organization. My preference is for Deming methods which form the foundation of lean and I also am a big fan of design of experiments (which most Deming and lean efforts do not use).

My father taught me design of experiments and Deming methods as a child and both have always made a great deal of sense to me. He wrote with George Box and Stu Hunter, what is seen by many as the premier design of experiments textbook, Statistics for Experimenters and he taught management improvement based on Deming's ideas, statistics, successful evidence based management principles... for decades.

These tools and methods all can be used together. A blog post of mine from 2005 on lean, six sigma, Deming, operational excellence and other management ideas.

SPC - Charting and Improving Results

Everett Clinic Video, Redux – The Need for SPC Thinking

Looking at 5.x% and comparing it against an arbitrary goal does little to tell us about the health of the work system. Is 5.x% the typical average performance? Is that much higher than usual?

This is a great opportunity to use the methods of Statistical Process Control. The main management decision is to decide "react" or "not react" to that daily data point. SPC helps us with this (again, Wheeler’s brilliant little book explains this far better than I can in a blog post).

If we choose “not react” because 5.x% is lower than the goal, we might be missing an opportunity for process improvement. Generally, it’s better to present more than one data point – even if you don’t do full-blown SPC, you should present a run chart.

Well put. A simple run chart can be very helpful. One of the uses is to identify special causes. And then to use special cause thinking in those cases. What is important about special cause thinking? That you want to identify what is special about the data point (instead of focusing on all the results as you normally would). What is important about doing that? You want to do it right away (not a week or a month later). Keeping the chart lets you identify when to use special cause thinking and react quickly (to fix problems or capture good special causes to try and replicate them).

You have to be careful as we tend to examine most everything as a special cause, when most likely it is just the expected result of the system (with normal variation in the data). Special cause thinking is not an effective strategy for common cause results.

Related: Quality, SPC and Your Career - Statistical Engineering Links Statistical Thinking, Methods and Tools