Posts about Quality tools
agile management blogs Books Career Carnival commentary continual improvement Creativity curiouscat Customer focus customer service Data Deming Economics economy engineering executive pay Google Health care Innovation internet Investing IT Japan John Hunter leadership lean manufacturing Lean thinking management managing people Manufacturing Performance Appraisal Process improvement Psychology Quality tools quote respect for people Six sigma Software Development Statistics Systems thinking tips Toyota Toyota Production System (TPS) webcast
Full tag cloud

Why Use Lean if So Many Fail To Do So Effectively

Posted on February 15, 2012  Comments (6)

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 System – Rethinking or Moving Beyond Deming Often Just Means Applying More of What Dr. Deming Actually Said – Management Advice Failures – Management Improvement Flavors – Has Six Sigma Been a Success?

Agile Story Point Estimation

Posted on February 8, 2012  Comments (0)

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 Fixes – Mistake Proofing the Deployment of Software Code – Checklists 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 →

Trust But Verify

Posted on January 16, 2012  Comments (2)

The following are my comments, which were sparked by question “Trust, but verify. Is this a good example of Profound Knowledge in action?” on the Linked In Deming Institute group.

Trust but verify makes sense to me. I think of verify as process measures to verify the process is producing as it should. By verifying you know when the process is failing and when to look for special causes (when using control chart thinking with an understanding of variation). There are many ways to verify that would be bad. But the idea of trust (respect for people) is not just a feel-good, “be nice to everyone and good things happen”, in Deming’s System of Profound Knowledge.

I see the PDSA improvement cycle as another example of a trust-but-verify idea. You trust the people at the gemba to do the improvement. They predict what will happen. But they verify what does actually happen before they run off standardizing and implementing. I think many of us have seen what happens when the idea of letting those who do the work, improve the process, is adopted without a sensible support system (PDSA, training, systems thinking…). It may actually be better than what was in place, but it isn’t consistent with Deming’s management system to just trust the people without providing methods to improve (and education to help people be most effective). Systems must be in place to provide the best opportunity to succeed. Trusting the people that do the work, is part of it.

I understand there are ways to verify that would be destructive. But I do believe you need process measures to verify systems are working. Just trusting people to do the right thing isn’t wise.

A checklist is another way of “not-trusting.” I think checklists are great. It isn’t that I don’t trust people to try and do the right thing. I just don’t trust people alone, when systems can be designed with verification that improves performance. I hear people complaign that checklists “don’t respect my expertise” or have the attitude that they are “insulting to me as a professional” – you should just trust me.

Sorry, driving out fear (and building trust – one of Deming’s 14 points) is not about catering to every person’s desire. For Deming’s System of Profound Knowledge: respect for people is part of a system that requires understand variation and systems thinking and an understanding of psychology and theory of knowledge. Checklists (and other forms of verification) are not an indication of a lack of trust. They are a a form of process measure (in a way) that has been proven to improve results.

Continue reading →

Eliminate the Waste of Waiting in Line with Queuing Theory

Posted on December 15, 2011  Comments (2)

One thing that frustrates me is how managers fail to adopt proven strategies for decades. One very obvious example is using queuing theory to setup lines.

Yes it may be even better to adopt strategies to eliminate as much waiting in line as possible, but if there is still waiting in line occurring and you are not having one queue served by multiple representatives shame on you and your company.

Related: Customer Focus and Internet Travel Search – YouTube Uses Multivariate Experiment To Improve Sign-ups 15% – Making Life Difficult for Customers

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

Posted on December 5, 2011  Comments (0)

I posted an interesting document to the Curious Cat Management Library: it includes Dr. Deming’s comments as part of a discussion organized by the Government Accounting Office in 1980 on Quality in Japan and the United States.

The document provides some interesting thoughts from Dr. Deming and others; Dr. Deming’s statements start on page 52 of the document. For those really interested in management improvement ideas it is a great read. I imagine most managers wouldn’t enjoy it though (it isn’t giving direct advice for today, but I found it very interesting).

Some selected quotes from the document follow. On his work with Japan in 1950:

This movement, I told them, will fail and nothing will happen unless management does their part. Management must know something about statistical techniques and know that if they are good one place, they will work in another. Management must see that they are used throughout the company.
Quality control must take root with simple statistical techniques that management and everyone in the company must learn. By these techniques, people begin to understand the different kinds of variation. Then quality control just grow with statistical theory and further experience. All this learning must be guided by a master. Remarkable results may come quick, but one has no right to expect results in a hurry. The learning period never ends.

The statistical control of quality is not for the timid and the halfhearted. There is no way to learn except to learn it and do it. You can read about swimming, but you might drown if you had to learn it that way!

One of the common themes at that time was Deming’s methods worked because Japanese people and culture were different. That wasn’t why the ideas worked, but it was an idea many people that wanted to keep doing things the old way liked to believe.

There may be a lot of difference, I made the statement on my first visit there that a Japanese man was never too old nor too successful to learn, and to wish to learn; to study and to learn. I know that people here also study and learn. I’ll be eighty next month in October. I study every day and learn every day. So you find studious people everywhere, but I think that you find in Japan the desire to learn, the willingness to learn.

You didn’t come to hear me on this; there are other people here much better qualified than I am to talk. But in Japan, a man works for the company; he doesn’t work to please somebody. He works for the company, he can argue for the company and stick with it when he has an idea because his position is secure. He doesn’t have to please somebody. It is so here in some companies, but only in a few. I think this is an important difference.

At the time the way QC circles worked in Japan was basically employee led kaizen. So companies that tried to copy Japan told workers: now go make things better like the workers we saw in Japan were doing. Well with management not changing (and understanding Deming’s ideas, lean thinking, variation, systems thinking…) and staff not given training to understand how to improve processes it didn’t work very well. We (those reading this blog) may all now understand the advantages one piece flow. I can’t imagine too many people would jump to that idea sitting in their QC circle without having been told about one piece flow (I know I wouldn’t have), and all the supporting knowledge needed to make that concept work.

QC circles can make tremendous contributions. But let me tell you this, Elmer. If it isn’t obvious to the workers that the managers are doing their part, which only they can do, I think that the workers just get fed up with trying in vain to improve their part of the work. Management must do their part: they must learn something about management.

Continue reading →

Management Blog Posts From October 2006

Posted on October 25, 2011  Comments (0)

I have selected a few posts from the Curious Cat Management Blog back in October 2006 for those of you who were not reading this blog then.

  • Why Pay Taxes or be Honest – “I don’t think acting illegally, immorally, unethically is excusable just because lots of other people are… It is sad how bad the behavior is that is considered acceptable.”
  • Hiring the Right Workers – “The job market is an inefficient market. There are many reasons for this including relying on specifications… Hiring is one of the area I think we could use some real innovation. I think much more flexibility would help.” I don’t feel as though any real progress has been made on better hiring in the last 4 years.
  • Righter Performance Appraisal – I know it is a silly title, but it is still one of my favorite blog post titles :-)
    • photo of Longwood Gardens

    Longwood Gardens. Delaware by John Hunter.

  • Deming Institute Conference: Tom Nolan – there are many important elements to managing well. Turning the PDSA cycle quickly is close to the top of those elements.
  • Google Shifts Focus – “Now that they have a bunch of decent, but not really great products, adjusting and taking the opportunity to improve those product makes sense.” You might think this is about the new initiatives Google’s new CEO, Larry Page, has been discussing but it isn’t. It is about one of Google’s previous efforts to focus and eliminate less important “distractions.”
  • Simple Cell Phone – “I don’t think these features are only desired in poor countries, but I am not basing that on any market research just my opinion. Complex devices with many points of failure (both technical failure and user inability to figure it out) should not be the only option.

Not Ambiguous Sign

Posted on August 18, 2011  Comments (0)

I like the series of posts by Jon Miller on Ambiguous signs (another example). Here is a sign that got my attention recently and they succeeded in keeping me away (which I think was their intention).

photo of sign showing gunman shooting someone, and warning in 5 languages not to enter

Photo in Johor Bahru, Malaysia near the Royal Palace by John Hunter.

The area is near the Royal Palace in Johor Bahru Malaysia, though I am not certain that is what the restricted area is. It isn’t obvious to me why this location requires shooting trespassers, but I took the idea from the sign to stay out. To me, this sign conveys pretty forcefully that you shouldn’t consider entering if you are not authorized to do so.

Related: Living in Malaysia – bear warning sign on hiking trail – Visual Instructions Example

Visual Management with Brown M&Ms

Posted on August 15, 2011  Comments (2)

When you hear about rock musicians having a clause in their contract that they must have a bowl of M&Ms in their dressing room with all the brown M&Ms removed you could be excused for thinking: what will these crazy celebrities do next. Well it might just be those crazy celebrities are using visual management (granted I think there could be better methods [a bit more mistake proofing where the real problems would be manifest] but it is an interesting idea). Basically if they didn’t have the bowl of M&Ms, or if the brown M&Ms were not removed, they could distrust the thoroughness of the contractors. And they would check to see what other, actually important, contractual requirements were not followed.

Righting The Wrongs: Van Halen and M&Ms

The staff at venues in large cities were used to technically-complex shows like Van Halen’s. The band played in venues like New York’s Madison Square Garden or Atlanta’s The Omni without incident. But the band kept noticing errors (sometimes significant errors) in the stage setup in smaller cities. The band needed a way to know that their contract had been read fully. And this is where the “no brown M&Ms” came in. The band put a clause smack dab in the middle of the technical jargon of other riders: “Article 126: There will be no brown M&M’s in the backstage area, upon pain of forfeiture of the show, with full compensation”. That way, the band could simply enter the arena and look for a bowl of M&Ms in the backstage area. No brown M&Ms? Someone read the contract fully, so there were probably no major mistakes with the equipment. A bowl of M&Ms with the brown candies? No bowl of M&Ms at all? Stop everyone and check every single thing, because someone didn’t bother to read the contract. Roth himself said:

“So, when I would walk backstage, if I saw a brown M&M in that bowl . . . well, line-check the entire production. Guaranteed you’re going to arrive at a technical error. They didn’t read the contract. Guaranteed you’d run into a problem. Sometimes it would threaten to just destroy the whole show. Something like, literally, life-threatening.”

Related: The Importance of Making Problems Visible – Visual Work Instructions – Good Process Improvement Practices – Great Visual Instruction Example

Good Execution Can Make Management Tools Like Time and Motion Studies Useful

Posted on August 11, 2011  Comments (0)

In my experience most management concepts are applied poorly. Many of the concepts may also be bad. For example, performance appraisals are both done poorly and a bad idea. The solution is not to do performance appraisal righter: for what to do read Peter Scholtes.

But, many tools and concepts that are applied with poor results, where the actual application is criticized (with good reason), can be used successfully. I would put benchmarking and time and motion studies in that category. Most of the time they are done poorly and produce bad results. But they can be done well, and provide value, so long as you have the right management system surrounding it and execute well. In practice I think, one thing that helps separate good managers from bad ones, is knowing how your organization will actually execute (not just dreaming about how nice things could be if only…) and not just trying things that they should know will produce bad results in their organization.

Based on my comment on: Time & Motion Studies Are Not “Discredited,” Just How They Are Used

Related: Improvement Tools and Improving Management – How to Get a New Management Strategy, Tool or Concept Adopted – Checklists in Software Development

One factor at a time (OFAT) Versus Factorial Designs

Posted on May 25, 2011  Comments (2)

Guest post by Bradley Jones

Almost a hundred years ago R. A. Fisher‘s boss published an article espousing OFAT (one factor at a time). Fisher responded with an article of his own laying out his justification for factorial design. I admire the courage it took to contradict his boss in print!

Fisher’s argument was mainly about efficiency – that you could learn as much about many factors as you learned about one in the same number of trials. Saving money and effort is a powerful and positive motivator.

The most common argument I read against OFAT these days has to do with inability to detect interactions and the possibility of finding suboptimal factor settings at the end of the investigation. I admit to using these arguments myself in print.

I don’t think these arguments are as effective as Fisher’s original argument.

To play the devil’s advocate for a moment consider this thought experiment. You have to climb a hill that runs on a line going from southwest to northeast but you are only allowed to make steps that are due north or south or due east or west. Though you will have to make many zig zags you will eventually make it to the top. If you noted your altitude at each step, you would have enough data to fit a response surface.

Obviously this approach is very inefficient but it is not impossible. Don’t mistake my intent here. I am definitely not an advocate of OFAT. Rather I would like to find more convincing arguments to persuade experimenters to move to multi-factor design.

Related: The Purpose of Factorial Designed Experiments – Using Design of Experiments – articles by R.A. Fisher – articles on using factorial design of experiments – Does good experimental design require changing only one factor at a time (OFAT)? – Statistics for Experimenters

Factorial Designed Experiment Aim

Posted on April 25, 2011  Comments (2)

Multivariate experiments are a very powerful management tool to learn and improve performance. Experiments in general, and designed factorial experiments in particular, are dramatically underused by managers. A question on LinkedIn asks?

When doing a DOE we select factors with levels to induce purposely changes in the response variable. Do we want the response variable to move within the specs of the customers? Or it doesn’t matter since we are learning about the process?

The aim needs to consider what you are trying to learn, costs and potential rewards. Weighing the various factors will determine if you want to aim to keep results within specification or can try options that are likely to return results that are outside of specs.

If the effort was looking for breakthrough improvement and costs of running experiments that might produce results outside of spec were low then specs wouldn’t matter much. If the costs of running experiments are very high (compared with expectations of results) then you may well want to try designed experiment values that you anticipate will still produce results within specs.

There are various ways costs come into play. Here I am mainly looking at the costs as (costs – revenue). For example the case where if the results are withing spec and can be used the costs (net costs, including revenue) of the experiment run are substantially lower.
Continue reading →

Assigning Story Points to Bug Fixes

Posted on January 27, 2011  Comments (1)

Agile software development has teams estimate the effort to deliver requests from the product owner. The estimates are done in points (in order to abstract away from hours – as estimates have plenty of variation in how long they will really take). Then the teams capacity (velocity) is determined based on looking at how many points they complete in a “sprint” (a set length, often 2 weeks). Then the product owner can prioritize all of the requests with an understanding of how much effort each is estimated to take and the historical capacity of the development team.

I think it is good to add point estimates to bugs. It may well impact how bugs are prioritized – if it is known to be simple a program manager may say, yes I want these 6 first then… If then know the first 2 are likely to take a bunch of time, they may think, ok, I am not going to get these 4 for awhile… They might just accept that, or may wish to shift more hours to bug fixes this sprint. Or they might say well if it is that big an issue maybe we could do x instead…

In practice I rarely has us estimate emergent bugs we are going to fix in the current sprint, but we do it for bugs that are in the backlog. I sometimes will have us estimate a current bug if I think it is may take significant time – to help determine what we really want to and what the impact may be on the teams output for the sprint. We do not have many emergent significant bugs so it isn’t much of an issue for us.

We do have more difficulty accurately estimating bugs, compared to new stories, but we still provide actionable estimates (they are not perfect, but are usable).

We use agile software development principles at work and they have been a great help in letting us be much more effective than we had been previously. The discussion of priorities and delivery expectations are much improved by such methods I believe. And unrealistic expectations can be reduced. For various reason, without adopting some form of agile/lean… software development methods the common pattern I see is software developers being frustrated by unrealistic expectation of their customers (project managers…) being frustrated by failure to communicate what it is reasonable to expect and status updates. A big part of this is the failure to acknowledge variation (and the related difficulty in estimation). Agile/Kanban… are systems that take the variation into account, and therefore the variation is dealt with as natural instead of leading to bad outcomes for developers and their customers.

Response to Should story points be assigned to a bug fixing story.

Related: Future Directions for Agile Management – Mistake Proofing Deployment of Software Applications – Checklists in Software Development

Annual Management Blog Review: Software, Manufacturing and Leadership

Posted on January 9, 2011  Comments (2)

In my contribution to the 3rd annual management blog roundup I will take a look at 3 blogs: Dennis Stevens, How to implement “Lean Thinking” in a Business and the Three Star Leadership Blog. This year 14 management bloggers contributed to highlight over 40 blogs, be sure to check out all the posts.

photo of Dennis Stevens

Dennis Stevens


Dennis Stevens writes a blog of the same name focused on agile software development principles with a strong focus on Dr. Deming’s ideas and lean thinking.

  • What’s Deming got to do with Agile – “Deming is not about manufacturing. He is about showing management how to create an environment for success. Deming is about culture – and his System of Profound Knowledge creates an environment that is especially effective for knowledge work… In knowledge work, where products are invisible, impact can be difficult to demonstrate. Kanban clearly shows progress and demonstrates the contribution of each person to the delivery of value. Additionally, PDSA provides opportunities for everyone to contribute to improving the quality of the organization’s capabilities.”
  • Kanban Mental Models and Double Loop Learning – “the Kanban cycle supports continuous learning that the team internalizes. Argyris’s model gives us some insight into why Kanban teams are consistently achieving double-loop learning and rapid maturity.”
  • We are Doing QQ All Wrong- “Developers should be using tools that support automated unit testing and only checking in code that passes all their unit tests… Test driven development or test just after development should be ubiquitous – but it is not. Continuous Integration environments that ensure that each check-in results in a valid and testable platform help teams perform integration and build validation.”
  • Shorten and Reduce Variability in Lead Times Using Kanban – ” identify and leverage strategies like reducing waiting, reducing rework, making work ready, defining small size work, and swarming, to improve lead time. Tracking causes of defects and blockages can help make decisions to focus these strategies appropriately. Reducing lead time duration and variability will result in increased predictability, faster feedback, improved flexibility and responsiveness.”
photo of Tracey Richardson

Tracey Richardson

Tracey Richardson writes the How to implement “Lean Thinking” in a Business blog focused on the lean manufacturing and the Toyota Production System.

  • Common Mistakes when we are Problem Solving – “Not utilizing the ‘Power of the gemba’,–or often referred to as “Go see the work/process“.!! I often see teams working together in a room trying to solve the problem by using their experiences, hypothetical guesses, and what their opinion is. I quickly disperse the huddle to “go-see” with their own eyes the current situation.”
  • How many different types of A3′s are there? – “I will briefly describe the 4 different types of A3′s and when to use them based on my experience: Problem Solving A3, Proposal A3, Status Report A3, Strategic Planning A3. All A3′s should follow the PDCA thinking regardless of which type you are working on.”
  • Why is asking “Why” so important? – “It is important to ask why repeatedly when visiting the gemba to determine what is current happening versus what should be happening. In many cases we stop at a symptom to the problem because we are often pressured for results and quickly solving the problem without going past the symptom seems to be the best answer.” [this one is actually from 2009 but I included it anyway - John]

Building Adoption of Management Improvement Ideas in Your Organization

Posted on December 8, 2010  Comments (5)

Continuation of How to Get a New Management Strategy, Tool or Concept Adopted

Target something that actually provides a good story. It often helps if there have been failures in attempts to solve a problem in the past. That makes the new success more impressive. Something that is relate-able to the audience you are trying to win over is also useful. Even if senior management cares about an issue, if the solution is so technical they are completely baffled, they will be happy with a solution but they won’t be as excited about expanding the strategy you are trying to encourage when they can understand the process that lead to a solution.

Favor efforts that will help you build organizational capacity to do more of what you want going forward (adopt lean thinking, use design of experiments…). Some of this is about building expertise in the organization. It is also about building your circle of influence. Growing your ability to influence how the organization grows will help you encourage the improvements you believe in.

It is very helpful to show connections between individual efforts. Often you build using various tools: in several instances using PDSA cycle to guide improvement, in others mistake-proofing to cement improvement, in another adopting one piece flow to make problems visible and encourage improvement, in another assuring the respect for people to build the right culture for improvement, and in another using an understanding of variation to make evidence based decision rather than jumping to faulty conclusions with limited information. These management tools, concepts, methods and ideas any many more, are used together for a reason. They support each other. So it is very helpful if you tie them together. As you start adding new tools, ideas and concepts to the management system show how they support each other. Individual tools can help. But the gains they offer are minor compared to the gains possible with a systemic change of management.

Another good strategy is picking the right people to involve in an effort. If you are trying to gain support, find those people in the organization that set the tone that others follow (which are not merely those with organizational power due to their job title). It is nice if you can find such people that have generally positive outlooks and like new challenges (this is often the case). If the culture is very toxic you may well have some who are likely to try and discourage hope in others (often because they have been disappointed so many times themselves they have finally decided not to be disappointed again). Often (though not always) you can win these people over.
Continue reading →

How to Get a New Management Strategy, Tool or Concept Adopted

Posted on December 6, 2010  Comments (6)

Often when learning about Deming’s ideas on management, lean manufacturing, design of experiments, PDSA… people become excited. They discover new ideas that show great promise to alleviate the troubles they have in their workplace and lead them to better results. But how to actually get their organization to adopt the ideas often confounds them. In fact, I believe most potential improvements efforts may well fail even before they start because people can’t get past this problem.

I believe the way to encourage adoption of management improvement tools, methods and ideas is to solve people’s problems (or give them new opportunities). Instead of trying to convince people by talking about why they need to adopt some new ideas, I think it is much better to show them. To encourage the adoption of whatever it is (a philosophy like Deming or a new tool) try to find projects that would be good candidates for visible success. And then build on those successes.

For adopting whole new ways of working (like lean thinking) you go through this process many times, adding more and more new ideas to the accepted way of doing things. It is a bit easier if you are the CEO, but I think the strategy is very similar whoever you are. For smaller efforts a boss can often just mandate it. But for something like a large improvement in the way work is done (adopting a lean management system, for example), the challenge is the same. You have to convince people that the new methods and ideas are valuable and that they can use the ideas to help improve results.

Start small, it is very helpful if initial efforts are fairly small and straight forward. You often will have limited resources (and limited time people are willing to invest) at first. so start by picking projects that can be accomplished easily and once people have seen success more resources (including what is normally the most important one – people’s time) should be available. Though, honestly getting people to commit will likely be a challenge for a long time.

It is a rare organization that adopts a continual improvement, long term focus, system thinking mindset initially. The tendency is often strong to focus on fire fighting, fear (am I taking a risk by doing x, if I spend time improving y – what about the monthly target my boss is measuring me on…) and maintaining the status quo. It is baffling to many hoping for improvement, when you have huge successes, and yet the old way of doing things retains a great hold. The inertia of organizations is huge.
Continue reading →

Airport Security with Lean Management Principles

Posted on November 16, 2010  Comments (1)

The ‘Israelification’ of airports: High security, little bother

We [Israel] said, ‘We’re not going to do this. You’re going to find a way that will take care of security without touching the efficiency of the airport.”
…
“The whole time, they are looking into your eyes — which is very embarrassing. But this is one of the ways they figure out if you are suspicious or not. It takes 20, 25 seconds,” said Sela. Lines are staggered. People are not allowed to bunch up into inviting targets for a bomber who has gotten this far.

Lean thinking: customer focus, value stream (don’t take actions that destroy the value stream to supposedly meet some other goal), respect for people [this is a much deeper concept than treat employees with respect], evidence based decision making (do what works – “look into your eyes”), invest in your people (Israel’s solution requires people that are good at their job and committed to doing a good job – frankly it requires engaged managers which is another thing missing from our system).

The USA solution if something suspicious is found in bag screening? Evacuate the entire airport terminal. Very poor design (it is hard to over-emphasis how poor this is). It will take time to design fixes into physical space, as it always does in lean thinking. It has been nearly 10 years. Where is the progress?

The Colbert Report Mon – Thurs 11:30pm / 10:30c
Tip/Wag – TSA, Bert & Dogs<a>
www.colbertnation.com
Colbert Report Full Episodes 2010 Election March to Keep Fear Alive
A screener at Ben-Gurion has a pair of better options. First, the screening area is surrounded by contoured, blast-proof glass that can contain the detonation of up to 100 kilos of plastic explosive. Only the few dozen people within the screening area need be removed, and only to a point a few metres away.

Second, all the screening areas contain ‘bomb boxes’. If a screener spots a suspect bag, he/she is trained to pick it up and place it in the box, which is blast proof. A bomb squad arrives shortly and wheels the box away for further investigation.

This is a very small simple example of how we can simply stop a problem that would cripple one of your airports,” Sela said.

Lean thinking: design the workspace to the task at hand. Obviously done in one place and not the other. Also it shows the thought behind designing solutions that do not destroy the value stream unlike the approach taken in the USA. And the better solution puts a design in place that gives primacy to safety: the supposed reason for all the effort.
Continue reading →

Good Process Improvement Practices

Posted on November 8, 2010  Comments (2)

Good process improvement practices include:

  • standardized improvement process (pdsa, or whatever)
  • Going to the gemba – improvement is done where the work is done. You must go to the where the action is. Sitting in meeting rooms, or offices, reading reports and making decisions is not the way to improve effectively.
  • evidence based decision making, data guides decision making rather than HiPPO
  • broad participation (those working on the process should be the ones working on improving it and everyone in the organization should be improving their processes)
  • measurable results that are used to measure effectiveness
  • pilot improvement on a small scale, after results are shown to be improvements deploy standardized solutions more broadly
  • visual management
  • Standardized work instructions are used for processes
  • one of the aims of the improvement process should be improving peoples ability to improve over the long term (one outcome of the process should be a better process another should be that people learned and can apply what they learned in future improvements)
  • quality tools should be used, people should be trained on such tools. The tools are essentially standardized methods that have been shown to be effective. And most organization just ignore them and struggle to reinvent methods to achieve results instead of just applying methods already shown to be very effective.
  • the improvements are sustained. Changes are made to the system and they are adopted: this seems obvious but far too often process improvements are really just band-aids that fall off a few weeks later and nothing is done to sustain it.
  • goals, bonuses and extrinsic motivation are not part of the process
  • The improvement process itself should be continually improved

Continue reading →

Managing Our Way to Economic Success

Posted on August 23, 2010  Comments (0)

From Managing Our Way to Economic Success, Two Untapped Resources by William G. Hunter, my father. Written in 1986, but still plenty relevant. We have made some good progress, but there is much more to do: we have barely started adopting these ideas systemically.

there are two enormously valuable untapped resources in many companies: potential information and employee creativity. The two are connected. One of the best ways to generate potential information to turn it into kinetic information that can produce tangible results is to train all employees in some of the simple, effective ways to do this. Rely on their desire to do a good job, to contribute, to be recognized, to be a real part of the organization. They want to be treated like responsible human beings, not like unthinking automatons.
…
W. Edwards Deming has illustrated one of the troubles with U.S. industry in terms of making toast. He says, “Let’s play American industry. I’ll burn. You scrape.” Use of statistical tools, however, allows you to reduce waste, scrap, rework, and machine downtime. It costs just as much to make defective products as it does to make good products. Eliminate defects and other things that cause inefficiencies, and you reduce costs, increase quality, and raise productivity. Note that quality and productivity are not trade-offs. They increase together.
…
Potential information surrounds all industrial processes. Statistical techniques, many of which are simple yet powerful, are tools that employees can use to tap and exploit this potential information so that increasingly higher levels of productivity, quality, and innovation can be attained. Engaging the brains as well as the brawn of employees in this way improves morale and participation…and profits.
…
What is called for is constant, never-ending improvement of all processes in the organization. What management needs, too, is constant, never-ending improvement of ideas.

Related: William Hunter, articles and books – Invest in New Management Methods Not a Failing Company – The Importance of Management Improvement – Statistics for Experimenters

Statistical Engineering Links Statistical Thinking, Methods and Tools

Posted on June 3, 2010  Comments (0)

In Closing the Gap Roger W. Hoerl and Ronald D. Snee lay out a sensible case for focusing on statistical engineering.

We’re not suggesting that society no longer needs research in new statistical techniques for improvement; it does. The balance needed at this time, however, is perhaps 80% for statistics as an engineering discipline and 20% for statistics as a pure science.

True, though I would put the balance more like 95% engineering, 5% science.

There is a good discussion on LinkedIn:

Davis Balestracci: Unfortunately, we snubbed our noses at the Six Sigma movement…and got our lunch eaten. Ron Snee has been developing this message for the last 20 years (I developed it in four years’ worth of monthly columns for Quality Digest from 2005-2008). BUT…as long as people have a computer, color printer, and a package that does trend lines, academic arguments won’t “convert” anybody.
…
Recently, we’ve lost our way and evolved into developing “better jackhammers to drive tacks”…and pining for the “good ol’ days” when people listened to us (which they were forced to do because they didn’t have computers, and statistical packages were clunky). Folks, we’d better watch it…or we’re moribund

Was there really a good old days when business listened to statisticians? Of course occasionally they did, but “good old days”? Here is a report from 1986 the theme of which seems to me to be basically how to get statisticians listened to by the people that make the important decisions: The Next 25 Years in Statistics, by Bill Hunter and William Hill. Maybe I do the report a disservice with my understanding of the basic message, but it seems to me to be how to make sure the important contributions of applied statisticians actually get applied in organizations. And it discusses how statisticians need to take action to drive adoption of the ideas because currently (1986) they are too marginalized (not listened to when they should be contributing) in most organizations.
Continue reading →

People Cannot Multitask

Posted on May 24, 2010  Comments (1)

There is plenty of research showing that people can’t multitask. But this knowledge is missed by many people. Here is another study showing this: Why We Can’t Do 3 Things at Once

That’s because, when faced with two tasks, a part of the brain known as the medial prefrontal cortex (MFC) divides so that half of the region focuses on one task and the other half on the other task. This division of labor allows a person to keep track of two tasks pretty readily, but if you throw in a third, things get a bit muddled.

“What really the results show is that we can readily divide tasking. We can cook, and at the same time talk on the phone, and switch back and forth between these two activities,” said study researcher Etienne Koechlin of the Université Pierre et Marie Curie in Paris, France. “However, we cannot multitask with more than two tasks.”

Now I wouldn’t base my judgement on this one study. But we don’t have to. Multitasking decreases productivity. The siren song of multitasking. Multi-tasking: why projects take so long. What we should strive for is flow, the opposite of multi-tasking.

The real world often requires dealing with many interruptions (forcing you not to multi-task but to break up your tasks into fragments). Single piece flow shows the value (the efficient system performance) of getting one thing done then picking up the next. Many interruptions force you to keep stopping and starting tasks. People think they are multi-tasking but in fact they are just doing 4 tasks serially switching back and forth between them. Which slows them down and increases the odds of forgetting something. In these environments checklists are even more important than if you are not being interrupted frequently.

Related: costs of context switching – The Multi-Tasking Myth – Interruptions Can Severely Damage Performance

  • Recent Trackbacks

  • Comments