Your World Is Not Red or Green

Your dashboards shouldn’t be, either

Mon, 06/18/2012 - 10:30

I recently closed the doors of my own consulting company on the prairie in Minnesota and headed back into the wild, wacky, wonderful world of larger consulting groups, joining a group in Northern Virginia. One of the consequences of that transition was that I was unable to meet a couple of speaking engagements, so I promised to write something about dashboards for the people who had planned to attend. This dashboard issue is one of the more egregious problems I see regularly.

ADVERTISEMENT

Although I can’t really put that whole presentation in writing, I can at least discuss the problem. The presentation was actually a half-day workshop that included W. Edwards Deming’s Red Bead experiment as an opening, followed by a discussion and brief overview of statistical process control (SPC). I see so few people using SPC anymore; most of the companies I work with measure very little and use their data badly. I wanted to include the Red Bead experiment because I consider it a prerequisite, the price of entry. If you understand the red bead, you’d probably never use an idiot-light dashboard.

 …

Want to continue?
Log in or create a FREE account.
By logging in you agree to receive communication from Quality Digest. Privacy Policy.

Comments

Submitted by Jeff Dewar on Wed, 06/20/2012 - 09:03

Rip, this is one of the best, succinct, and easy to read summaries of the whole arbitrary standards vs. process analysis arguments I've read in a very long time. This could very easily be the assigned reading prior the first class of any number of management topics.

Submitted by sdelizo on Wed, 06/20/2012 - 10:29

Nice article, but the intent shouldn't be applied solely to managers.  Anyone having to search for and resolve an issue within a process should have access to the data trends, be encouraged to understand thier meaning and tasked to generate measurable results.

It's interesting to me to be told often that "well, the control charts are just too complex...we need to make it simple for managers." I'm not sure what they see as complex...when Larry Sullivan first saw a group of Japanese workers discussing a control chart at Tokai Rika back in 1981, they were line workers...not company statisticians or consultants. While I completely agree with you that it should be just as you describe, I have found very few managers at any level in any organization who knew how to use data to manage their processes.

As an example, the manager of a pretty high-volume aluminum-cutting operation in a good-sized factory told me that yield was killing him...he just couldn't seem to get yield up high enough to make his operation profitable. I asked him, "So, what is the yield in this process?"

He replied, "I'm not sure...last quarter it was down around 73%." (There were only three weeks left in the current quarter).

I told him I wasn't interested in last quarter's numbers..."What is the yield today? What was it yesterday? Is it stable?"

He looked at me like I was an idiot, or an alien, or something. "I don't know what it is today, why would I know that? The quarterly numbers are what counts!" I told him yield would no doubt continue to kill him, and that things would stay just as they are until he decided it was important enough to study more than one day a quarter.

So while my intent isn't actually solely applied to managers, I think I have to try to reach them first. They are going to be the ones who have to implement the systems; they are the ones who decide what will comprise their dashboards.

It's interesting to me to be told often that "well, the control charts are just too complex...we need to make it simple for managers." I'm not sure what they see as complex...when Larry Sullivan first saw a group of Japanese workers discussing a control chart at Tokai Rika back in 1981, they were line workers...not company statisticians or consultants. While I completely agree with you that it should be just as you describe, I have found very few managers at any level in any organization who knew how to use data to manage their processes.

As an example, the manager of a pretty high-volume aluminum-cutting operation in a good-sized factory told me that yield was killing him...he just couldn't seem to get yield up high enough to make his operation profitable. I asked him, "So, what is the yield in this process?"

He replied, "I'm not sure...last quarter it was down around 73%." (There were only three weeks left in the current quarter).

I told him I wasn't interested in last quarter's numbers..."What is the yield today? What was it yesterday? Is it stable?"

He looked at me like I was an idiot, or an alien, or something. "I don't know what it is today, why would I know that? The quarterly numbers are what counts!" I told him yield would no doubt continue to kill him, and that things would stay just as they are until he decided it was important enough to study more than one day a quarter.

So while my intent isn't actually solely applied to managers, I think I have to try to reach them first. They are going to be the ones who have to implement the systems; they are the ones who decide what will comprise their dashboards.

Submitted by jandell on Wed, 06/20/2012 - 10:40

I had not anticipated that anybody would be goofy enough to set green and red (and even yellow) boundaries while utterly ignoring the concepts of common and special cause - but I suppose I should have. Nor did it occur to me that the zones might be set based on spec limits instead of process capabilities - but again, I suppose I should have.

I could possibly defend the color zones if they are based on the modified rules of pre-control -- yellow starts +/- 1.5 s from mean, red starts +/- 3 s from mean. This interpretation rectifies the critical vulnerability in the original pre-control, where the colors used to be set by spec limits rather than process performance.

However, I cannot and will not try to justify "idiot lights" as a replacement for a control chart with thoughtfully designed rational subgrouping.

I have a Facebook page I call "Quality Face Palm," where I describe immense blunders made in the name of quality. I would like permission to add the link to this article in that page.

Thoroughly enjoyed the article.  Wish more would read it and even more would take the lessons to heart.  I'm sure you've "been there" where they maybe get it and maybe don't but continue to do something else, anyway.  I think that's because the something else is the easy way and the right way takes understanding (requires knowledge - as Deming would say).

On a separate note, I'm sure you probably don't remember me from the DEN, but I was a student of some of your collegues in the Navy (and an organization level trainer/advisor myself).  I've followed (read) your writing and posting for years, always impressed with your knowledge and ability to communicate the concepts.  Keep up the good work.

Of course I remember you from the DEN, Greg. I miss the DEN...there are several Deming discussion groups around; several in LinkedIn. None, however is like the DEN. I wish now that I had copied all the messages from that group into a file and archived it. For a while, you could get to an archive on the Deming Institute site, but I can't find it there anymore. I've often thought that Jim Clauson could have put together a pretty interesting book (at least an e-book) of some of those threads. When you think about some of the posts, and the people that were writing those posts (Myron Tribus, David Kerridge, John Connelly, Bill Latzko, Frank Voehl, Mike Tveite), and the contributions many of them made (Myron and David sometimes wrote pages each day)...it was the leading edge of the quality literature in those years. 

 

Do you think we'll ever be rid of the horror of Cpk and Ppk, which are fatally flawed IMHO by the inclusion of the spec limits (I have yet to see spec limits that were statistically validated, and even if they were they still suffer from being static criteria in a dynamic universe).  The simple question is:  what kinds (centrality, dispersion, etc.) and values of variation are appropriate and how do we meet them?  This would bring engineers out of the safe, tidy world of drawings and cad files and change boards and such, but while the establishment of real feedback loops and the resources to support them might be painful for people and organizations, the harsh light of day can only help in the long run.

I'm reminded of the time I worked for a division of an american conglomerate that put its name on a pale imitation of TPS.  We were visiting a sister plant that made fasteners and other tiny high-volume parts.  IIRC, most of the shop floor was covered in woo (WIW - work in waiting;  I just made that up).  Our host remarked that they wanted to buy more machines but they didn't know where they would put them!

Your "woo" (I like that better than wip...I'll use that!) story reminded me of a company I worked with for a while...they were trying to learn TPS, and had asked me to come in for sort of a progress check. They had a 16-acre warehouse that they had built just to hold the excess woo that they couldn't find room for in the manufacturing plant. The founder of the company had pronounced, back in the '40s, that "Inventory is the price of good customer service."

One of the guys I was working with told me that, at one operation, they had needed a few hundred pieces of machined material. There were several pallets of it in the warehouse (already processed, waiting to be used). They sent someone looking for it. He found the material, but it was buried in the middle of a huge block of other material, and they estimated that it would take them more than a day to shift all the other stuff around so they could get to it (this in addition to the half-day the guy already spent searching). So they decided it would just be quicker and easier to machine a fresh pallet...

 

My opinion of your client's operation includes the word "cluster".  I hope they manage to shift their paradigm before it's the '40s again.  Sadly, in industry incompetence doesn't guarantee extinction.

The previous QD article "How Control Charts Can Provide Predictive Statements" also addresses these stoplight scorecard issues and provides a methodology where predictive scorecards can be used throughout the business in its decision making and improvement processes. Note also that Enterprise Performance Reporting System (EPRS) software can automatically capture and update these enhanced scorecards. The following link provide access to the article http://www.qualitydigest.com/inside/quality-insider-article/control-cha…

Add new comment