Tag Archives: Quality tools

Applying Improvement Concepts and Tools to Your Daily Life

This month the ASQ Influential Voices is taking a bit different approach. This month we are looking at applying quality tools in our personal life based on the post from other influential voice, Sunil Kaushik: How Lean Helped Me Travel To Egypt With Just $500.

Sunil is on a nomadic trip around the world to learn and enjoy the experience while also helping others applying lean thinking.

I just returned from my own nomadic adventure.

John Hunter at Marble Mountain - Buddha  statue in background

John Hunter, in a cave at Marble Mountain, Da nang, Vietnam. This is one of my last stops before returning home. See more of my travel photos

I have experience applying quality tools since I was a kid being guided by my father. Another influential voices author, that I met in Hong Kong when I presented a a Deming seminar, included a mention of that connection in his post: Quality Life and Succession.

In this blog I write about using management improvement thinking in my personal life. That extends from management concepts such as optimizing the entire system and not getting trapped by habit or convention, for example in: The Aim Should be the Best Life – Not Work v. Life Balance.

My father applied these ideas in our family life and so naturally they formed my way of thinking. At the core was a focus on experimentation and focusing on what was important. It is easy to spend a lot of time on things that really are not that important and questioning if the actions we are taking is really what we should be doing based on the most important aims was a natural part of how we thought growing up. In order to experiment effectively you need to be able to understand data and draw appropriate conclusions (post on an experience with my father as a child: Playing Dice and Children’s Numeracy).

Also we would look at what wasn’t giving the results we desired and experiment on how to improve. I include in “results” the happiness or frustration the process causes (so as a kid this was often the frustration my brother and I had in doing some task we didn’t want to do – cleaning our room, doing homework etc. and the frustration our parents felt at having to continually bring us back onto task). Much of this effort amount to setting the understanding and incentives and process to get better results (both the end results and increasing happiness and reducing frustration of all of us in the family).

A concept I use a good deal in my personal thinking on a more concrete level is mistake proofing (or at least mistake making less easy). Many people do this, without really thinking that is what they are doing. But by thinking of it consciously I find it helps you design processes to be most effective.

Continue reading

Visual Management and Mistake-Proofing for Prescription Pills

Good ideas often just require some sensible thought to think of an improved approach. Management concepts can help guide such thinking, such as mistake-proofing and visual management.

To apply visual management requires giving a bit of thought to how to make visually obvious what is important for people to know. Mistake proofing is often really mistake-making-more-difficult (for some reason this term of mine hasn’t caught on).

prescription pills packaged together

Image from PillPack, they provide a service to deliver packages based on your prescriptions.

I believe mistake-proofing should put barriers in the process that make a mistake hard. Often what is called mistake-proofing doesn’t really fit that definition. The pill package shown above for example, doesn’t prevent you from continuing past the time on the package (Monday at 8AM) without taking the pills.

To call it mistake-proofing I would like to see something that makes it harder to make the mistake of failing to take the pills: something that blocks progress beyond that time without taking the pills.

Even something as simple as an alert to your smart phone that gets your attention and doesn’t allow the smart phone to be used without indicating you have taken the pills would reach the “mistake-proofing” level in my opinion (for someone that has their phone with them at all times). The Apple Watch could be a good tool to use in this case. Even so those wouldn’t make mistakes impossible (you can say you took the pills even if you didn’t, the phone/watch may lose power…). It would depend on the situation; this smart phone/watch solution is not going to be good for some people.

Another idea is that these pill packages should be tied to the room (in a hospital) and at home if a home care nurse (or even family or others) are responsible for assuring the pills are taken with a big display that perhaps 30 minutes before the pill is due posts a message that says “pills to be taken at 8 AM” and once that time is past it could become more obvious, perhaps after 15 minutes it produces an audio alert. The actual solutions are going to be better from those that know the actual situation than someone like me just thinking up stuff as I type.

But the idea is pretty simple: when you have processes that are important and at risk of failure, design processes with elements to make mistakes hard (and ideas such as mistake-proofing and visual management can help you guide your mind to ways to create better processes).

The entire process needs to be considered. The pill packages are nice, because even in failure modes they provide good feedback: you may still fail to take them at the right time, but you can look at the location where the pill packages are kept and see
if any have a time before right now (in which case you can follow the medical guidance – take the pills right now, contact the doctor, or whatever that advice is). Of course even that isn’t foolproof, you could have put the package into your purse and it is still sitting in their but you forgot.

Still the pill packages seem like a good mistake-making-more-difficult solution. And it seems to me that process has room to make mistakes even more difficult (using a smartphone addition, for example).

Continual improvement requires a continual focus on the process and the end user for ways to increase reliability and value. Each process in question should have engaged people with the proper skills and freedom to act using their knowledge to address weakness in the current process that are most critical.

Failure to take prescriptions as directed in a common problem in health care. Knowing this should make those involved in the process think of how they can use concepts, such as mistake-proofing, to improve the results of the system.

Too often to much focus is on making better pills compared to the effort is put into how to improve results with simple concepts such as visual management and mistake-proofing.

Each small improvement contributes to creating a more robust and effective process. And engaged people should continually access how the containing systems, new processes and new capabilities may allow more small steps to provide value to those relying on your products and services.

Related: Great Visual Instruction Example for Taking PillsVisual Management with Brown M&MsQuick Mistake Proofing Ideas for Preventing Date Entry Error

Continue reading

Magnetic White-Board Kanban Card Options

Just some quick ideas for Kanban whiteboard magnetic card options from a question I answered on Reddit.

Here is the best lean solution: Trying Out My Agile Kanban Board from Jon Miller.

kanban board with magnetic whiteboad  cards

Magnetic kanban board from Jon Miller.

Why, well mainly I am kidding about it being the best, but if you don’t read his Gemba Panta Rei blog you should! Go add it to your RSS feed reader, before you continue with this post.

Ok, welcome back. In addition to thinking his blog is great the solution from his blog is very flexible and easy – though it isn’t quite a packaged solution (as asked for on Reddit). Also that post provides some good insight into the thinking behind the board (as well as how to create your own).

More links with kanban board options: Magnetic whiteboard cards (50-pack)Physical TaskboardsI think just magnetic symbols (not magnetic white board card) but could use magnet with icon to stick paper to the board

Another silly site, that sells some sort of solution, blocked my access because they don’t sell in the country my computer reported being located in. So I didn’t give them a free plug (assuming their product was decent which it might be?). Very dumb design if you ask me; well even though you didn’t ask, I told you anyway.

Localization that impedes users rather than helping them seems far far too common in my experience. Mapping (and related – find closest…) uses are about the only localization stuff I find useful – country based localization I nearly always find annoying or crippling. And showing my location on a map is totally awesome (especially as I travel around as a tourist – or really in whatever capacity). Such bad design and poor usability decisions cost companies money.

Related: Visual Management with Brown M&MsMaking Data VisibleDeming and Software Development

Root Cause, Interactions, Robustness and Design of Experiments

Eric Budd asked on The W. Edwards Deming Institute group on LinkedIn

If observed performance/behavior in a system is a result of the interactions between components–and variation exists in those components–the best root cause explanation we might hope for is a description of the interactions and variation at a moment in time. How can we make such an explanation useful?

A single root cause is rare. Normally you can look at the question a bit differently see the scope a bit differently and get a different “root cause.” In my opinion “root cause” is more a decision about what is an effective way to improve the system right now rather than finding a scientifically valid “root cause.”

Sometimes it might be obvious combination which is an issue so must be prevented. In such a case I don’t think interaction root cause is hard – just list out the conditions and then design something to prevent that in the future.

Often I think you may find that the results are not very robust and this time we caught the failure because of u = 11, x = 3, y = 4 and z =1. But those knowledge working on the process can tell the results are not reliable unless x = 5 or 6. And if z is under 3 things are likely to go wrong. and if u is above 8 and x is below 5 and y is below 5 things are in trouble…

To me this often amounts to designing systems to be robust and able to perform with the variation that is likely to happen. And for those areas where the system can’t be made robust for some variation then designing things so that variation doesn’t happen to the system (mistake proofing processes, for example).

In order to deal with interaction, learn about interaction and optimize results possible due to interactions I believe the best method is to use design of experiments (DoE) – factorial experiments.

Continue reading

George Box Webcast on Statistical Design in Quality Improvement

George Box lecture on Statistical Design in Quality Improvement at the Second International Tampere Conference in Statistics, University of Tampere, Finland (1987).

Early on he shows a graph showing the problems with American cars steady over a 10 years period. Then he overlays the results for Japanese cars which show a steady and significant decline of the same period.

Those who didn’t get to see presentations before power point also get a chance to see old school, hand drawn, overhead slides.

He discusses how to improve the pace of improvement. To start with informative events (events we can learn from) have to be brought to the attention of informed observers. Otherwise only when those events happen to catch the attention of the right observer will we capture knowledge we can use to improve. This results in slow improvement.

A control chart is an example of highlighting that something worth studying happened. The chart will indicate when to pay attention. And we can then improve the pace of improvement.

Next we want to encourage directed experimentation. We intentionally induce informative events and pay close attention while doing so in order to learn.

Every process generates information that can be used to improve it.

He emphasis the point that this isn’t about only manufacturing but it true of any process (drafting, invoicing, computer service, checking into a hospital, booking an airline ticket etc.).

He then discussed an example from a class my father taught and where the students all when to a TV plant outside Chicago to visit. The plant had been run by Motorola. It was sold to a Japanese company that found there was a 146% defect rate (which meant most TVs were taken off the line to be fixed at least once and many twice) – this is just the defect rate before then even get off the line. After 5 years the same plant, with the same American workers but a Japanese management system had reduced the defect rate to 2%. Everyone, including managers, were from the USA they were just using quality improvement methods. We may forget now, but one of the many objections managers gave for why quality improvement wouldn’t work in their company was due to their bad workers (it might work in Japan but not here).

He references how Deming’s 14 points will get management to allow quality improvement to be done by the workforce. Because without management support quality improvement processes can’t be used.

With experimentation we are looking to find clues for what to experiment with next. Experimentation is an iterative process. This is very much the mindset of fast iteration and minimal viable product (say minimal viable experimentation as voiced in 1987).

There is great value in creating iterative processes with fast feedback to those attempting to design and improve. Box and Deming (with rapid turns of the PDSA cycle) and others promoted this 20, 30 and 40 years ago and now we get the same ideas tweaked for startups. The lean startup stuff is as closely related to Box’s ideas of experimentation as an iterative process as it is to anything else.

Related: Ishikawa’s seven quality control tools

He also provided a bit of history that I was not aware of saying the first application of orthogonal arrays (fractional factorial designs) in industry was by Tippett in 1933. And he then mentioned work by Finney in 1945, Plackett and Burman in 1946 and Rao in 1947.

Interview on PDSA, Deming, Strategy and More

Bill Fox interviewed me and has posted part one of the interview on his web site: Predicting Results in the Planning Stage (sorry, the link has been hijacked to forward to an unrelated page [so obviously I removed the link], I have posted the interview which can now be reached here):

Bill: John, what is your best process improvement strategy or tactic that has worked well for you or your clients?

John: I would say the PDSA improvement cycle and a few key practices in using the PDSA properly like predicting the results in the plan stage—something that a lot of the times people do not do—to determine what would be done based on the results of that prediction.

People discover, especially when they’re new to this stuff, regarding the data that they’re collecting, that maybe even if they got the results they are predicting, they still don’t have enough data to take action. So you figure that even if that number is 30, they would need to know three other things before they make the change. So then, in the plan stage, you can figure that you need to address these other issues, too. At any time that people are collecting data is useful to figure out, for instance: “What do we need to do if the result is 30 or if the result is 3?” And if you don’t have any difference, why are you collecting the data?

Another important piece is the D in Plan, Do, Study, Act. It means “do the experiment”. A lot of times, people get confused into thinking that D means deploy the results or something like that, but thinking of D as ‘doing the experiment’ can be helpful.

A really big key between people that use PDSA successfully and those who don’t is that the ones that do it successfully turn the cycle quickly.

Another response:

Bill: What is the biggest misunderstanding about the Deming Management System you think people have?

John: I would say that there are a couple. The followers that want to pin everything to Deming tend to overlook the complexities and nuances and other things.

The other problem is that some of the critics latch on to a specific quote from Deming, something like a one-sentence long quote, and then they extrapolate from that one sentence-long quote what that means. And the problem is that Deming has lots of these one-sentence quotes that are very memorable and meaningful and useful, but they don’t capture every nuance and they don’t alone capture what it really means (you need to have the background knowledge to understand it completely).

They are sort of trying to oversimplify the message into these sound bites, and I find that frustrating. Because those individual quotes are wonderful, but they are limited to one little quote out of hours of videotape, books, articles, and when you don’t understand the context in which that resides, that’s a problem.

See the full interview for more details and other topics. I think it is worth reading, of course I am a bit biased.

Related: more interviews with John HunterInterviews with John Hunter on his book: Management MattersDeming and Software DevelopmentLean Blog Podcast with John Hunter

Resources for Using the PDSA Cycle to Improve Results

graphic image showing the PDSA cycle

PDSA Improvement cycle graphic from my book – Management Matters

Using the PDSA cycle (plan-do-study-act) well is critical to building a effective management system. This post provides some resources to help use the improvement cycle well.

I have several posts on this blog about using the PDSA cycle to improve results including:

The authors and consultants with Associates for Process Improvement have the greatest collection of useful writing on the topic. They wrote two indispensable books on the process improvement through experimentation: The Improvement Guide and Quality Improvement Through Planned Experimentation. And they have written numerous excellent articles, including:

Related: Good Process Improvement PracticesThe Art of Discovery (George Box)Planning requires prediction. Prediction requires a theory. (Ron Moen)

Jeff Bezos: Innovation, Experiments and Long Term Thinking

Jeff Bezos, bought the Washington Post. He has long showed a willingness to take a long term view at Amazon. He is taking that same thinking to the Washington Post:

In my experience, the way invention, innovation and change happen is [through] team effort. There’s no lone genius who figures it all out and sends down the magic formula. You study, you debate, you brainstorm and the answers start to emerge. It takes time. Nothing happens quickly in this mode. You develop theories and hypotheses, but you don’t know if readers will respond. You do as many experiments as rapidly as possible. ‘Quickly’ in my mind would be years.”

The newspaper business is certainly a tough one today – one that doesn’t seem to have a business model that is working well (for large, national papers). I figured the answer might be that a few (of the caliber of Washington Post, New York Times…) would be owed by foundations and supported largely by a few wealthy people that believed in the value of a strong free press and journalism. Maybe Bezos will find a business model that works. Or maybe he will just run it essentially as a foundation without needing a market return on his investment.

The Guardian (where the article with the quote was published) is an example of good journalism by a foundation. ProPublica is another (though I guess it is really a non-profit but most of the funding seems to be via foundations).

Related: Jeff Bezos and Root Cause Analysis (2009)Amazon Innovation (2006)Jeff Bezos on Lean Thinking (2005)Jeff Bezos Spends a Week Working in Amazon’s Kentucky Distribution Center (2009)

Design of Experiments: The Process of Discovery is Iterative

This video is another excerpt on the design of experiments videos by George Box, see previous posts: Introduction to Fractional Factorial Designed Experiments and The Art of Discovery. This video looks at learning about experimental design using paper helicopters (the paper linked there may be of interest to you also).

In this example a screening experiment was done first to find those factors that have the largest impact on results. Once the most important factors are determined more care can be put into studying those factors in greater detail.

The video was posted by Wiley (with the permission of George’s family), Wiley is the publisher of George’s recent autobiography, An Accidental Statistician, and many of his other books.

The importance of keeping the scope (in dollars and time) of initial experiments down was emphasized in the video.

George Box: “Always remember the process of discovery is iterative. The results of each stage of investigation generating new questions to answered during the next.”

Soren Bisgaard and Conrad Fung also appear in this except of the video.

The end of the video includes several suggested resources including: Statistics for Experimenters, Out of the Crisis and The Scientific Context of Quality Improvement.

Related: Introductory Videos on Using Design of Experiments to Improve Results (with Stu Hunter)Why Use Designed Factorial Experiments?brainstormingWhat Can You Find Out From 12 Experimental Runs?

Stated Versus Revealed Preference

My father provided me a good example of the flawed thinking of relying on stated preference when I was growing up. Stated preference is, as you might deduce, the preferences voiced by customers when you ask. This is certainly useful but people’s stated preference often do not match there actions. And for a business, actions that lead to customers are more important than claims potential customers make about what will make them customers.

His example was that if you ask people if clean bathrooms in a restroom is required for a restaurant they will say yes. Potential customers will say this is non-negotiable, it is required. But if you eat at many “ethnic restaurants,” as we always did growing up, you would see many popular restaurants did not have clean restrooms. If the food at atmosphere was good enough clean restrooms were negotiable, even if customers stated they were not.

Now I think clean restrooms is a wise move for restaurants to make; it matters to people. Instead of creating a barrier to repeat customers that has to be overcome with much better food and atmosphere it is wiser to give yourself every advantage by giving the customers what they want. But I think the example is a simple example of stated versus revealed preferences.

McDonald’s gets a great deal of success by doing certain things well, including clean bathrooms, even if they miss on things some people think are important for a restaurant. McDonald’s really gets a fair amount of business for people driving a long distance that really want a clean bathroom and a quick stretch of their legs and quick food. This is a small percentage of McDonald’s customer visits but still a very large number of visits each day I am sure. Understanding, and catering to, the problem your customers are trying to solve is important.

The point to remember is what your potential customers say they will do is different than what they do. It is sensible to listen to stated preferences of customers just understand them for what they are.

We need to pay more attention to revealed preferences. Doing so can require putting in a bit more thinking than just asking customers to fill out a questionnaire. But it is worth the effort. A simple restaurant based example would be to have wait staff pay attention to what people leave on their plate. If you notice certain side dishes are not eaten more often, look into that and see what can be done (improving how it is prepared, substituting something else…).

Related: Voice of the CustomerThe Customer is the Purpose of Our WorkCustomers Are Often IrrationalPackaging Affects Our Perception of TasteBe Careful What You Measure

Management Blog Review 2012: Gemba Walkabout

This is my second, of two, 2012 management blog review posts. In this post I look back at the last year on Mike Stoecklein’s Gemba Walkabout blog. Mike is the Director of Network Operations at Thedacare Center for Healthcare Value.

photo of Mike Stoecklein
  • In a very long post, Some thoughts on guiding principles, values & behaviors, he provides a sensibly explanation for one the real difficulties organization have making progress beyond a certain point (project success but failure to succeed in transforming the management system). “I’m not saying this approach (focus on tools, teams, events) is wrong, but I do think it is incomplete. I think we also need to work from right to left – to help people understand the guiding principles, to think about the kinds of systems they want and to use tools to design and redesign those systems. Dr. Shigeo Shingo said, ‘people need to know more than how, they need to know why’.

    Most managers view their organization like an org chart, managed vertically. They assume that the organization can be divided into parts and the parts can be managed separately

    It’s what they believe, and what they don’t know is that is is wrong – especially for a complex organization.
    If their thinking was based on the guiding principles (for instance “think systemically”) they would manage their organization differently. They would see their organization as as set up interdependent components working together toward a common aim.”
  • Reflections on My (Brief) Time with Dr. Deming – “The executives thought he was pleased. When they were done with their ‘show’ he thanked them for their time, but he wanted to know what ‘top management’ was doing. He pointed out that they were talking about improvements on the shop floor, which accounted for only about 3 percent of what was important.” When executives start to radical change what they work on the organization is starting to practice what Dr. Deming taught. Mike recorded a podcast with Mark Graban on working with Dr. Deming.
  • Standard Work and PDSA – “What I have noticed is that sometimes people insert another wedge (shown as black) in the diagram below. So, progress gets stopped because some seem to believe that standard work doesn’t get adjusted as you make improvement.” This is a brilliant graphic including the text standard work misued. The 2 biggest problem with “standard work” in practice is ignoring the standards and treating them as barriers to improvement. Standard work should be practiced and if that is a problem the standard work guidance should be changed.
image showing how failure to adjust standard work can block progress

During the year stay current with great posts twice a month via the Curious Cat Management Improvement Carnival.

Related: Management Blog Review 2012: Not Running a Hospital2011 Management Blog Roundup: Stats Made EasyStandardized Work InstructionsAnnual Management Blog Review: Software, Manufacturing and Leadership

Special Cause Signal Isn’t Proof A Special Cause Exists

One of my pet peeves is when people say that a point outside the control limits is a special cause. It is not. It is an indication that it likely a special cause exists, and that special cause thinking is the correct strategy to use to seek improvement. But that doesn’t mean there definitely was a special cause – it could be a false signal.

This post relies on an understand of control charts and common and special causes (review these links if you need some additional context).

Similarly, a result that doesn’t signal a special cause (inside the control limits without raising some other flag, say a run of continually increasing points) does not mean a special cause is not present.

The reason control charts are useful is to help us maximize our effectiveness. We are biased toward using special cause thinking when it is not the most effective approach. So the control chart is a good way to keep us focused on common cause thinking for improvement. It is also very useful in flagging when it is time to immediately start using special cause thinking (since timing is key to effective special cause thinking).

However, if there is result that is close to the control limit (but inside – so no special cause is indicated) and the person that works on the process everyday thinks, I noticed x (some special cause) earlier, they should not just ignore that. It very well could be a special cause that, because of other common cause variation, resulted in a data point that didn’t quite reach the special cause signal. Where the dot happened to land (just above or just below the control limit – does not determine if a special cause existed).

The signal is just to help us systemically make the best choice of common cause or special cause thinking. The signal does not define whether a special cause (an assignable cause) exists of not. The control chart tool helps guide us to use the correct type of improvement strategy (common cause or special cause). But it is just a signaling device, it isn’t some arbiter of whether a special cause actually exists.

Continue reading

5s at NASA

NASA did some amazing things culminating with landing on Moon. Much of what they did was doing many small things very well. They used 5s, checklists, gemba thinking, usability, simplicity, testing out on a small scale and much more.

Here are a few photos from the Smithsonian Air and Space museum in Washington DC. I also have some nicer NASA 5s photos from the new Annex near Dulles Airport, but, ironically, I can’t find them.

photo of container labeled with many compartments for NASA

These kits were used by NASA astronauts on the Apollo 11 mission to the moon. Obviously NASA had to have everything that might be needed where it was needed (picking up something from the supply closet in building 2 wasn’t an option).

Continue reading

Value Stream Mapping for Fun and Profit

Guest post by Evan Durant, author of the Kaizen Notebook blog.

I tend to get a little preachy about the importance of value stream maps, but they really can be useful tools not only to plan an improvement effort but also to monitor your progress going forward. In particular they provide a way to quantify the impact of changes to your process. Here’s a real life example as a case in point.

For a particular value stream a team went to gemba, followed the flow of material and information, collected process cycle times, and counted inventory. When everything was mapped and all the data tallied, here was the current state that they came up with:

Total Lead Time:
   
16.8 days
Process Lead Time: 2.2 days
Process Time: 1.9 days
Operator Cycle Time: 8.2 minutes

So what does all this mean? First of all the Total Lead Time represents the amount of time that a new piece of raw material would take to enter the value stream, be worked on, wait around with all the rest of the material in process, and then finally make its way to the customer. This number is usually driven higher by large amounts of in-process inventory caused by pushing between operations.

Second, the Process Lead Time is the amount of time it would take to process a single batch through the process, if it didn’t have to wait behind any other batches. Note that even though parts are processed one at a time through all of the manual operations, a certain amount of batching is required to overcome long machine cycle times in automatic operations. Also we do not ship parts to the customer one at a time, but rather in standard package sizes.

Third, we have the Process Time. This is the total amount of value added time, manual and automatic processing, that a part sees in the value stream.

Finally the Operator Cycle Time (also called manual time) is the amount of actual “touch” time required to make a part. The difference between the Process Time and the Operator Cycle Time is the Machine Cycle Time (also called automatic time). This is when a batch of parts is on a machine that does not require any operator intervention during a cycle. (We have a lot of machine cycle time in this value stream.)

Then the team applied the concepts of flow and pull to reduce overproduction and pace the value stream to the rate of customer demand. The results of the future state map were as follows:

Continue reading

Moving Beyond Product Quality

This month Paul Borawski (CEO of ASQ) has asked the ASQ Influential Voices to share their thoughts on moving beyond product quality.

The opening paragraph of the Quality Council’s perspective is, “For some organizations, ‘quality’ remains a set of tools and techniques associated almost exclusively with quality control. For others, quality has evolved into a critical partner, closely linked with business model development and the enterprise-wide execution of long-term strategy to achieve results.

The way to move beyond just the set-of-tools mindset is very similar to the March topic on selling quality improvement.

What is needed to move beyond quality tools into a new management system is to make changes to the system that allow for that management system to be continually improved. Using the tools helps improve product quality a great deal. Much more can be done (both for product quality and overall effectiveness) if we don’t limit the use of modern improvement efforts to the manufacturing line.

At first it is often difficult to get managers and executives to accept the kind of change to their work that they will direct others to make. But once the process of improving the management system gets started, it takes a life of its own and is a very strong force to move beyond product quality.

Here are some previous posts on methods and strategies to move forward the organization into adopting a customer focused systemic effort to continuously improve every aspect of the organization – including the management system:

Related: Dr. Deming in 1980 on Product Quality in Japan and the USA

Richard Feynman Explains the PDSA Cycle

Ok, really Richard Feynman Explains the scientific method. But his thoughts make the similarity between the PDSA cycle and the scientific method obvious.

1) Plan, hypothesis.
You make a guess about a theory (in using the PDSA cycle this step is often missed, while in the scientific method this is of the highest priority). You make a prediction based on that theory.

2) Do the experiment

3) Study the results

If the results disprove the theory you were wrong. If they results don’t disprove the theory you may have a useful theory (it can also be that your theory is still wrong, but this experiment happened not to provide results that disprove it).

Step 4, Act, only exists for PDSA. In science the aim is to learn and confirm laws. While the PDSA cycle has an aim to learn and adopt methods that achieve the desired results.

Richard Feynman: “If it disagrees with experiment it is wrong, in that simple statement is the key to science, it doesn’t make any difference how beautiful your guess is, it doesn’t make a difference how smart you are (who made the guess), or what his name is, if it disagrees with experiment it is wrong.”

Actually far to often “PDSA” fails to adopt this understanding. Instead it become PA: no study of the results, just implement and we all already agree it is going to work so don’t bother wasting time testing that it actually does. Some organization do remember to study results of the pilot experiments but then forget to study the results when the new ideas are adopted on a broader scale.

Related: Does the Data Deluge Make the Scientific Method Obsolete?Video of Young Richard Feynman Talking About Scientific ThinkingHow to Use of the PDSA Improvement Cycle Most EffectivelyUsing Design of Experiments

Management Blog Posts From November 2006

I have selected a few great posts from the Curious Cat Management Blog back in November 2006.

  • What Could we do Better? – There are many important ideas to improve management. This is one of the most important tips to aid improvement that I know of: it is easy to do, brings huge benefits and most organizations fail to do it. Ask your customers: “What one thing could we do to improve?”
  • Ackoff’s F-laws: Common Sins of Management presents 13 common sins of management, such as: Managers who don’t know how to measure what they want settle for wanting what they can measure
  • Common Cause Variation – “Every system has variation. Common cause variation is the variation due to the current system. Dr. Deming increased his estimate of variation due to the system (common cause variation) to 97% (earlier in his life he cited figures as low as 80%). Special cause variation is that due to some special (not part of the system) cause.”
  • Sub-Optimize by Interrupting Knowledge Workers – “The general consensus is that the loss from interrupting [software] developers is much greater than for interrupting most other forms of work and therefor a great deal of effort is placed on improving the system to allow developers to focus.”
  • Amazon Innovation – “I believe Amazon uses technology very well. They have done many innovative things. They have been less successful at turning their technology into big profits. But I continue to believe they have a good shot at doing so going forward (and their core business is doing very well I think).” [Amazon announced great sales numbers today, continuing their long term tread. They are also continuing to be very slow to grow profits (CEO, Jeff Bezos remains willing to challenge common practices – such as his willingness to build business and sacrifice current profits)].

Keys to the Effective Use of the PDSA Improvement Cycle

The PDSA improvement cycle was created by Walter Shewhart where Dr. Deming learned about it. An improvement process is now part of many management improvement methods (A3 for lean manufacturing, DMAIC for six sigma and many other modifications). They are fairly similar in many ways. The PDSA cycle (Plan, Do, Study, Act) has a few key pieces that are either absent in most others processes of greatly de-emphasized which is why I prefer it (A3 is my second favorite).

The PDSA cycle is a learning cycle based on experiments. When using the PDSA cycle prediction of the results are important. This is important for several reasons but most notably due to an understanding of the theory of knowledge. We will learn much more if we write down our prediction. Otherwise we often just think (after the fact); yeah that is pretty much what I expected (even if it wasn’t). Also we often fail to think specifically enough at the start to even have a prediction. Forcing yourself to make a prediction gets you to think more carefully up front and can help you set better experiments.

An organization using PDSA well will turn the PDSA cycle several times on any topic and do so quickly. In a 3 month period turning it 5 times might be good. Often those organizations that struggle will only turn it once (if they are lucky and even reach the study stage). The biggest reason for effective PDSA cycles taking a bit longer is wanting more data than 2 weeks provides. Still it is better to turn it several times will less data – allowing yourself to learn and adjust than taking one long turn.

The plan stage may well take 80% (or even more) of the effort on the first turn of the PDSA cycle in a new series. The Do stage may well take 80% of of the time – it usually doesn’t take much effort (to just collect a bit of extra data) but it may take time for that data to be ready to collect. In the 2nd, 3rd… turns of the PDSA cycle the Plan stage often takes very little time. Basically you are just adjusting a bit from the first time and then moving forward to gather more data. Occasionally you may learn you missed some very important ideas up front; then the plan stage may again take some time (normally if you radically change your plans).

Remember to think of Do as doing-the-experiment. If you are “doing” a bunch of work (not running an experiment and collecting data) that probably isn’t “do” in the PDSA sense.

Study should not take much time. The plan should have already have laid out what data is important and an expectation of what results will be achieved and provide a good idea on next steps. Only if you are surprised (or in the not very common case that you really have no idea what should come next until you experiment) will the study phase take long.

Continue reading

Why Use Lean if So Many Fail To Do So Effectively

If less than 1% of companies are successful with Lean, why are we doing it?

Lots of us are not. I would say the efforts I see “fail” are because they don’t do it. They have something they call TQM, six sigma, lean management or whatever and try out 10-30% of it in some half-measures, with big doses of Dilbert’s pointy haired boss methods and then don’t get great results. Wow.

The biggest complaint (with some merit) I see is why is lean/Deming/six sigma… so hard to actually do. If companies constantly fail to do it at all (even when they use the name) isn’t that an issue. Isn’t that a weakness of the “solution.” My answer is: yes. The caveat is, until someone comes up with the management system that both gets the results using Deming’s management ideas can, and is super easy for organizations to actually fully adopt (and have the great success that doing so provides) I know of nothing better than trying to do these things.

Certainly I believe you are much better off attempting to use Deming, lean or six sigma than listen to someone that tells you they have management instant pudding that will give you great results with no effort.

My belief is that a partial success rate is much higher than 1%. While many organization never go beyond slapping a few good tools on a outdated management system those few tools actually have good results. Maybe 50% of the implementations are so lame they have almost no positive results (not even getting improvement worth the time and effort). They could be seen as “failures,” to me. Those that actually have a right to say they are practicing “lean” I would say is a pretty small number but still above 1%?

There is also an advantage to this stuff being hard to do. You really don’t have to invent anything new. If you just have persistence and keep continually improving along the path applying ideas proven over decades from Deming, Ohno, McGregor, Christensen, Drucker, Scholtes, Womack, Roger Hoerl (six sigma)… you have a great advantage over all those organizations that ignored the ideas or made a bit of effort and then gave up.

Related: Engage in Improving the Management SystemRethinking or Moving Beyond Deming Often Just Means Applying More of What Dr. Deming Actually SaidManagement Advice FailuresManagement Improvement FlavorsHas Six Sigma Been a Success?

Agile Story Point Estimation

In agile software development tasks are documented as user stories. Then the level of effort for those stores can be estimated by assigning each story points. The velocity that can be produced in a period (called a sprint, for us 2 weeks) can be estimated. Thus you can predict what can be delivered in the next sprint (which can help business managers make priority decisions).

I have found estimation to be worthwhile. In doing so, we accept there is a great amount of variation but points give a hint to scale. They can help prioritize (if you have 5 things you want but 1 is much harder you may well drop that to the bottom). I have always accepted a great amount of variation in the velocity, worry about the variation I don’t find worthwhile. I do think trying to act as though the velocity is precise can lead to problems. At the same time having a measure of velocity, even accepting understanding variation was present, was useful.

Over time reducing variation (probably largely through better estimation and perhaps a few better tools, reduced technical debt, better documentation, testing…) is helpful and laudable. We made improvement but still lots of variation existed. The biggest help in reducing the measured velocity was breaking down large stories to more manageable sizes. The challenge of estimating user stories, I suspect, has some fairly high variation (even with good system improvements that can help reduce variation).

Large stories just can hide huge variation in what is really required once getting into implementing it.

The way we did estimation (discussing in a sprint planning meeting) did take some time (but not a huge amount). It was agreed by those involved that the time spent was worthwhile. Sometimes we did slip and spend too much time on this, that was an area we had to pay attention to. The discussions were educational and helped provide guidance on how to approach the story. The value of discussions around estimations was probably the biggest surprise I have had in implementing any agile ideas. The value of those discussion was much higher than I imagined (I basically anticipated them just as non-value added time to get the result of an estimate, but they were a source of learning and consensus building).

Related: Assigning Story Points to Bug FixesMistake Proofing the Deployment of Software CodeChecklists in Software Development

These thoughts were prompted by: Story Points Considered Harmful – Or why the future of estimation is really in our past…

Continue reading