PDCA – Page 2 – The Lean Thinker

May 7, 2013January 9, 2019

Embracing instability

Kaizen is largely a drive toward stability – that is a more consistent operation, producing a more consistent result. The key is the definition of “consistent.”

Overproduction is a way to achieve the illusion of consistency in the face of inherently unstable operations. Your machines are unreliable? Run faster when you can run. Inconsistent quality? Make more stuff so you have enough good ones.

And you know what? If my machines are unreliable, I do run faster. I put in buffers of time and material. I have to, because at the end of the day, I need to satisfy the customer.

The difference is in what I am trying to do, and how I define “stable.”

If I were to define “stable” as “I don’t have to pay attention to this” then my natural reaction will be to bury the problem by building in accommodations – things I “have to do” because “the process isn’t stable.”

Once there are sufficient accommodations in place, I, as a manager, could shift my attention elsewhere.* We all know the downside of this – those problems accumulate, and eventually the system fails completely. But our brains are programmed to assign cause to recent events, even if they were simply the tipping point.

The reflex reaction, then, is to look at something that just happened, assume that was the problem (since everything was “fine” before), and find a short term fix to make it go away.

I see this quite a bit. That is why I am now quite… inquisitive about the ongoing process improvement efforts if I hear a target condition as some level of performance, and “the process is stable” as the current condition.

No problem is a big problem.

*I may very well put in a temporary countermeasure so I don’t have to deal with all of the obstacles and problems at once. It looks the same if you are touring the shop floor. The difference is intent.

May 2, 2013January 9, 2019

Rapid PDCA

This sub-assembly line had a planned cycle time of 15 minutes. The most skilled and experienced assembler could almost get all of the work done in that time, but generally, two people were required to consistently deliver without stopping the main line.

Among other obstacles identified, the first assembly step was being done on a bench. This required the assembler to stabilize the main part with one hand, position the part being installed with another hand, and hold the tool with… you get the idea.

The idea was to design and build a jig that would hold the main part steady, in the right orientation, at a good working height.

Iteration 1: Mock up the concept.

Rodney (the lean manager) and Maegan (the line team leader) are showing their first iteration of concept.

But even before this, their real first experiment was to hold the part by hand and test where it needed to be stabilized. The cardboard mock-up was a confirmation.

Iteration 2:

They experimented with contact points and hold points and made a few adjustments…

Iteration 3: Have a more robust version made out of wood, try it with an actual part.

Learned: The part isn’t stable enough to work on.

Next experiment: Add a clamp, and mount it to a tool stand.

Then Maegan tries it out.

What did we learn?

It is difficult to get the tools behind the clamp bar.

Iteration 4:

Add some wood shims to raise the part and see if that works better.

Expected result: Should be easier to get the tool in there. Now try it.

But we learned we need a better backstop for the clamp.

Iteration 5

Which seems to have done the trick.

This, plus a couple of other changes, got the cycle time under the 15 minutes, so one person could do this job.

All of this happened over less than a couple of hours. A far cry from the traditional tooling and jig design process.

Follow-Up:

This is the final version. As you can see, there is now a wedge under the clamp to change the angle + some additional clamps that allowed the tool to also be used for another subsequent operation.

November 8, 2012January 9, 2019

Finding Patterns

“What is your target condition?”

“One-by-one flow, meeting an 11 minute planned cycle time, with two people.”

“What is your current condition now?”

“We are making rate, but our lowest repeatable times add up to 28 minutes, and with that and the 32% variation we are seeing, we need 3 people on the line to do it consistently.”

“Where is all of that variation coming from? What are people struggling with?”

“All of the assemblies are different!”

And this was kind of true. We had five different larger assemblies firing in a repeating cycle:

A, B, C, A, D, E, A, B, C, A, D, E

And to make the discussion more interesting, each of these items has four sub-assemblies, of different types, that go into it. This line was building those sub-assemblies in a sequence that matched the need. So it is easy to see why all of that variation seemed overwhelming.

But there was commonality, a lot of it. The operations were very similar, with the differences being things like:

A left-hand or right-hand difference.
An operation is included, or excluded from a particular sub-assembly.
Differences in geometry that had little or no bearing on the actual operations being conducted.

My goal was to lead them to doing more detailed observations, seeing the blind assembly operations, chaotic layout on the bench, the occasional hunt for information, and at this point, the learning curve the assemblers are still coming down as we identify key points.

We are hard-wired to see differences in things – that blade of grass is bent, is there a tiger there? Sometimes it is more challenging to seek out and become aware of the underlying patterns. In other words, what these items have in common.

Rather than looking at obstacles to build the parts, we want to look at the obstacles to smoothly carrying out the operations. It is a subtle difference, but an important one. Sometimes you have to search through the noise to find the signal.

As of this writing, the bench is getting better organized, tools are getting homes, and some assembly aids and tools are being developed to avoid having large fingers trying to get things done in small places.

The work is starting to stabilize enough that the patterns are becoming more visible, which allows capturing the work breakdown in a rational way that can be taught – first the base industrial skills, then the common operations, then the sequence of those operations for specific parts.

We’ll get there.

October 24, 2012January 9, 2019

What is the ROI for That Log?

I still see companies struggle to apply a financial return on every improvement proposed.

PC has made an excellent analogy in a post on the forum. Rather than repeat it here, I’ll give you the link, maybe we can get a conversation started.

http://forums.theleanthinker.com/viewtopic.php?f=9&p=903#p903

(Sidebar: I am pretty aggressive about deleting accounts that look like spammers. If I got yours by mistake, write to me at “Contact Mark” on the right sidebar, and I’ll fix it.)

October 20, 2012January 9, 2019

Some PDCA Cycles

We had five sequential operations. Although the lowest repeatable times for each were well within the planned / target cycle time, there was a lot of variation.

Though Operation 3 was working pretty continuously, Operations 4 and 5 (downstream) were getting starved on occasion, and the empty “bubble” was working its way to the output. The exit cycles, therefore, were irregular enough that they weren’t making rate.

The team set their target to stabilize Operation 3, with the expectation that doing so would smooth out the overall exit cycles.

To that end, they went back and started to study Operation 3 in a little more detail to better understand the obstacles that were impacting the Team Member’s ability to complete the work smoothly.

Then a wrinkle – a different team member was now doing the work, and his cycles were faster.

This actually was an opportunity. Why is one Team Member faster than another?

Their hypothesis was that the faster Team Member had some knack or technique, that enabled him to perform more consistently. And indeed, he did have a few tricks.

So the first experiment was to capture this work cycle in a Job Breakdown, then see if using Job Instruction and teaching it to the first Team Member they could duplicate the results of the second.

Then another wrinkle. The first team member was back on the job. Armed with the knowledge gained by breaking down the steps, key points and reasons for Team Member #2, they took more baseline data from Team Member #1 to set up their experiment.

…only to discover that Team Member #1 was also doing things that #2 didn’t do.

One of those things was unbending a part that was sometimes being bent by an upstream operation.

It seems that #2 was just passing those along as he got them. With that background, the conversation went something like this:

“What obstacle are you addressing?”

“The manual rework in Operation 3 is adding variation and extending his cycles.”

“What experiment are you running next?”

“We think the jig being used in Operation 1 is a bit undersize, allowing the part to deform. We are going to adjust the jig to the proper size.”

“What do you expect from that?”

“We expect to eliminate bent and deflected parts, and see more consistency in Operation #3’s cycles.”

Then they tried it. Skipping ahead a bit:

“What actually happened?”

“The parts are now more consistent, and there Operation #3 has a lot less variation, and is running closer to the planned cycle time… except that now he is waiting on parts from the upstream operation.”

“Huh. What is happening there? What did you just learn?”

“Well, it looks like Operation #3’s variation was masking inconsistent delivery from Operation #2. That team member is operating in small batches, then turning and delivering 3-5 parts at a time. When there was a lot of variation in Op #3, those parts were kind of buffering everything. Now he is working more consistently and faster, and ends up waiting on parts.”

“Because of the layout, the Operation #2 Team Member has to turn to his left and pass the parts behind him. He said he batches so he doesn’t have to turn so often. So what we are thinking is we want to…”

“Hang on, I want to stick to the structure so you guys can practice hearing and responding to it… So – what is your next step?”

“We talked to the team members, and they all agree that if we straighten out that bend in the layout, this will be a lot easier on them, so we are going to do that during the lunch break.”

“And what do you expect from that?”

“Operation #3 will get his parts one-by-one, as they are ready, and won’t have to wait on them.

“Great, so when can we see what you have learned?”

“Give us about 30 minutes after lunch break is over.”

You can probably surmise that things smoothed out a bit.

Then they went back to capturing a hybrid of the best practices of both operators in a job breakdown. At this point, the Team Members were genuinely interested in how they were doing, and both were quite open to learning the “tricks” of the other, so “Get the worker interested in learning the job” had pretty much been done.

A lot was learned over a few hours.

Reflection:

The “real world” is often quite a bit messier than the real world. There was actually a lot more dialog than I reconstructed here to keep the “learners” on track and focused on their stated target vs. resorting to an action of “improvements.”

In addition, merely beginning to work on one obstacle revealed enough information that they were dealing with a different underlying problem.

At another point in the week, they also believed they saw a need for more consistent part presentation. I happened to agree with them, but…

when pressed for what result they expected, the initial response was “The parts will be consistently presented.”… but what does that have to do with your target?

That was tough because, at the time, they were looking at the cycles of the 2nd operator that were, actually, pretty consistent, and lost sight of the fact that they were working on reducing the overall variation of output from that position.

They had a very hard time articulating why consistent part presentation would address the issue, even though they knew it should.

I think this is the result of years of conditioning that the “tools” – such as consistent part presentation – are good for their own sake, without really examining the underlying problems and causes that are being addressed.

If we lean practitioners are scratching our heads wondering why people don’t see this stuff helps, it would be a lot easier to deal with if we could point to the issue being addressed at the moment.

More tomorrow.

November 20, 2011January 9, 2019

Theory Tests Reality, Reality Tests Theory

“Experience by itself teaches nothing… Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence, without theory, there is no learning.”

–W. Edwards Deming, The New Economics for Industry, Government, Education – 2nd Edition

The field of psychology, it seems, shares an issue with the field of operations management.

Wilson and Golonka, psychologists who blog on Notes From Two Scientific Psychologists lament about the lack of a unifying theory in their field in Theory, and Why Its Time Psychology Got One.

This is fairly heavy reading since it is likely from outside your field, but the core message is here (paragraph breaks added for readability):

Theory in Science
As I try to teach my students, the role of theory in science is to provide structure to your data. A good theory rules explanations in and out, and if it rules out the wrong explanation that will become clear over time as you pursue your theory guided research.

Good science means a) restricting your explanatory mechanisms to include things your theory allows, and b) keeping an eye on how well that’s working out for you, while c) allowing yourself to rest on your well supported theory to resist breaking the rules as long as you can.

As Deming points out in the quote at the top of this post, having a theory – a solid statement of what you believe is true is a prerequisite for learning to take place. Without that theory, events and information simply get filed away as “interesting.”

With a theory, each is compared against the prevailing thought and forces us to reflect on our understanding.

Sure, we run into confirmation bias (where we unconsciously exclude things that contradict our beliefs) and other logical flaws, but honestly – if scientific thinking were easy, we wouldn’t have to discuss it.

This is pertinent to us at a couple of levels.

At the macro-level we have the proliferation of “solutions” out there for management. We all talk about “flavors of the month” and “alphabet soup” as we see companies cycle through the various structures for “world class performance.”

Wilson and Golonka’s message, and our problem, is that in attempting to embrace everything, we embrace nothing.

Of course part of the problem is that book authors and management consultants are not, by and large, researchers who are interested in unifying the theory. Quite the contrary. They are interested in differentiation. This causes problems for people who see these various “solutions” as competing somehow. (In reality, they are mostly re-packaging of subsets of the same overall stuff.)

OK, we can’t do much about that in the larger sense, but within your company, you can.

I have yet to encounter a situation that is outside of my baseline theory of “what TPS is.”

As I said in a talk I gave last week, the only faith-based position I am asking you to embrace is that if your results seem incompatible with TPS, look at your understanding and deployment before rejecting it as unworkable.

While we wait for the MBA programs and influential institutions in our field to catch up, we can continue to identify in forums like this one which authors and researchers we think are largely congruent with one another and some kind of common baseline.

The other area where this message is applicable is in our daily approach to process design and problem solving.

Almost all of the “tools of lean” (and many techniques not especially associated with TPS) are really designed to develop and test a working theory of how the process should be working.

Takt time is a great example, though far from the only one.

I set up a process to operate at a certain speed. I say, in effect, “if the process has no unexpected problems, this is how long it should take.”

That is a theory.

I test the theory each and every time I run the process.

When (not if) something unexpected happens – when the team member can’t meet the standard work for some reason, then we have data that is not congruent with our baseline theory.

Now we can get into understanding why – what happened that we didn’t count on. Likely (in this example) something uncontrolled tripped him up. In experimental terms, we didn’t have the baseline conditions.

In our process terms, we now have a problem to solve – how do we keep that issue from coming up again, so that our team member can do the work in the time expected?

As we cycle through this thinking again and again, each iteration either cleans up some issue in the operation (which is continuous improvement), or we realize that we should have included this factor in the original plan (we modify the working theory).

Either way, our knowledge of the process is improved.

In reality, these two cases – micro and macro – point to the same thing. We need the macro (the theory of management) to reflect that we need to incorporate this thinking into the way we manage everything.

May 29, 2011January 9, 2019

People Kaizen

Tommy raised an interesting question in his comment to Internalizing Outside Knowledge. He said:

In my company we are working with the developing people concept. Our objective is to make ourselves redundant, but it is hard. What are the best ways of developing people? How do you do it?

How do you do it indeed?

I don’t know the specific situation he is facing, but I can ask some questions that are pretty universal.

What, exactly, are you striving to achieve with your people development? What do you want people to be able to do that they are not doing now? What would that look like if you were to observe it? How would they be interacting with the process, with each other?

If you observe today, what do you actually see? How does that differ from what you described above?

What is the gap between what you want and what you have?

I ask these questions because often we talk about “developing people” but we don’t get specific about what we expect as a result. It is easy to set objectives for kaizen of processes, quality, output, cycle time, etc. But when we talk about people, we get squishy about it.

But the process of improvement remains the same, no matter what (or who) you are trying to improve. And the first step is to know two things:

The direction you are trying to move – the ideal, the True North.
The next target you are trying to hit now which will move you in that direction.
When you expect to be there.

Once you have that, it is time to take a look at what you are actually doing and ask how, exactly, that effort is expected to advance you toward your target.

If the answer to that question is not crystal clear, it is time to step back and reassess your approach. Likely your approach is general and broad-brushed, rather than focused.

What never works is telling people about improvement and expecting them to get excited enough by that message to fill in the details on their own. The idea that “once they grasp the true vision they will engage on their own” is a common one.

But consider this analogy. We all know that mathematics is a wonderful tool. I can tell you all about the great discoveries and engineering feats that mastery of mathematics has enabled. I can show you dozens of examples, even take you through demonstrations of how others have used mathematics to solve problems.

At the end, you might be fired up about math, but you still can’t do it. I may have motivated, but I have not developed anyone.

If I want you to actually use mathematics, I have to assess where their current skills are, establish the next step for them, and construct a situation where they must practice and struggle a bit, but not too much, to “get” the next understanding.

That is called “practice.”

So – back to the original question.

You want to develop people.

What are you having them practice for a little while every day?

How are you providing them immediate feedback on success or failure, and coaching them?

How are you checking your results against the results you intend? What are you doing to develop and improve your own process of people development?

PDCA

January 3, 2010January 9, 2019

Simple and Easy Processes

In the last post I commented on Ron Popeil’s product development approach – to make the product easy to demonstrate drives making it easy to use, which creates more value for the customer.

Let’s take the same thinking back to your internal customers.

What if, rather than just writing a procedure, you had to go and demonstrate it to the people who had to follow it? What if you had to demonstrate it well enough that they saw the benefit of doing it that way, and could demonstrate it back to you to confirm that they understood it? If you broke down the work and organized it to be easy to demonstrate and teach, would it look any different? (Hmmm. TWI Job Instruction actually sounds a lot like this.) Would you still ask “Why didn’t they just follow the procedure?”

Look at the information displays and the controls on your equipment. Do they provide total transparency that things are working? Or do they abstract and obscure reality in some way? Can your internal customer be sure things are going as expected?

Do controls give clear feedback that they are being set correctly? Are sequences of operations readily apparent?

How many “blinking 12:00” situations do you have out there on your shop floor – things that have been put into place, but nobody uses because nobody can really figure it out?

Come back to the design of the product itself. Is the manufacturing and assembly process apparent, obvious, and as simple as you can make it? Would it be designed differently if you had to demonstrate how to fabricate and assemble it?

How about your administrative processes? I recall, many years ago, a “process documentation process” being taught. In the class they were using “baking cookies” as a demonstration example. Yet the instructors, who presumably were experts, actually struggled trying to show how this works. This “process” was far less clear than they had thought it was when they had simply thought through it. “It did not work on TV.”

Look at your computer programs and their user interfaces. What makes sense to a programmer rarely makes sense in actual use. Watch over someone’s shoulder for a while. Could you easily demonstrate this process to someone else?

Ron Popeil cooks real chickens and real ribs in the production of his infomercials. He does not use contrived or carefully limited demonstration examples. As you look at your examples and exercises, how well do they stand up to the real world application? Can you go out to the shop floor and demonstrate your “product” in actual use?

This post is full of questions, not answers. I don’t have the answers. Only you (can) know how well your processes are engineered.

Design your production system (for product or service) as carefully as you would design the product or service itself.

November 13, 2009January 9, 2019

A “Problems First” Culture

I will be the first to tell you that this is probably repetition of a fairly narrow theme you have seen here before. But I think of different ways to frame it, or get different thoughts, so I share them.

“Problems first” is one of the mantras used by Phil Jenkinson, the CEO character in The Lean Manager by Michael and Freddy Ballé. Now that I have had a few weeks to let it sink in and synthesize with my mental models, I am seeing a concept that is so fundamental I would think it would be hammered into students in every management and leadership course taught in the world.

Of course, though, it isn’t.

Instead it seems alien in most company cultures.

Yet without a “problems first” culture, the leaders really have no idea – none at all – what they should be focusing their attention on. How could they? They don’t know what their people are struggling with until it is too late. By that point, a small unresolved problem has grown to the point where it cannot possibly be ignored, and now it must be dealt with. Task teams are formed, initiatives are launched. Action item lists are made and presented every week, and after enormous expense and effort, the illusion of control is returned. And so many companies are run just like this.

I am pretty sure that anyone reading this knows exactly what this feels like. Let me call it a “hidden problems” culture for now. Maybe I will think of a better term later.

Enough about what it isn’t.

Ironically, a lot of companies in the pursuit of “being lean” actually go blindly through the motions of “problems first,” but so in a way that raises questions about their understanding of this concept.

Let’s look at a simple action item review at a staff meeting.

Typically it looks like this:

For each action, the responsible person reports on the status, whether or not it is “on time” (usually against an arbitrarily assigned due date), and any “problems.” The manager asks if any help is needed, and perhaps assigns more actions to someone else to assist.

One common management tool for these things is a “Stoplight Chart” where actions are assigned color codes of Green, Yellow, or Red, usually depending on progress against the deadline (how late they are).

Red items get the most attention in the meeting (as they should, more about that in a minute), but that attention is usually in the framework of review and reporting.

At the end of the meeting, the senior leader has a good feel for what is happening (or what is not happening).

Contrast this with a world-class automobile assembly line.

Just like the actions items, every task has a deadline. Only in this case, the timing is much tighter – measured in seconds, not days. The assembler knows that if he gets more than 3-4 seconds behind, for any reason at all, he cannot possibly catch up and complete the work cycle on time. He is going to be late.

He pulls the andon cord, to let the team leader know there is a problem.

Key Point: This is not a report of a problem. This is transfer of the problem. The assembler is responsible for carrying out the work as it is designed. If he can’t, for any reason, then exceptions are transferred to the team leader.

The team leader can deviate from the standard work sequence to complete the job, but not the timing. If he cannot clear the problem by the end of the takt cycle, that section of the line will stop, and the andon will go red.

This is not a report of a problem, this is transfer of the problem. The team leader is responsible for assuring the work can be completed within the takt time. If he can’t, for any reason, then exceptions are transferred to the supervisor.

The supervisor is now responsible for clearing the problem and getting things moving again. If he can’t, then within a few minutes, another section of the line will be stopped and the responsibility for clearing the problem transfers to the next level in the chain.

And so it continues.

Of course this increasing level of responsibility does not mean that the others walk away. They are clearly working very hard to get the problem cleared. But each level of escalation brings more resources to bear on the issue.

Note that I haven’t talked about root cause and problem solving yet. Although the escalation procedures are designed to help gain better understanding of the underlying cause, the first priority is to get the problem cleared so that production can resume without compromising safety or quality in any way.

There may be a temporary countermeasure put into place to do this – some short term action that, while it might introduce some extra resources into the process, allows safe, quality production to proceed long enough to get to the underlying cause. One test of understanding that cause can be to remove this temporary crutch and see what happens.

OK, back to the staff meeting.

What is different about that?

The main thing is that typically the problems are being reported, but not escalated. The responsible person may have to come with an action plan to clear the issue, but it is still Management by PowerPoint, and the senior leader’s role is approval vs. involvement. If the senior leader does become involved, it is often driven by a perception that the responsible person is incapable rather than a process of professional development.

What would this look like if it were managed exactly the same way as the assembly line?

What if that monthly review were treated the same as the fixed stop position?

A couple of ideas come to mind.

“Green” means “on track, as originally scheduled.”

“Yellow” means “behind, but we have a plan to get back to green.”

“Red” means behind, and we don’t know how we are going to recover.”

How would those meanings change the tenor of these meetings?

“Problems first” is more than just a discussion about problems. It is a culture that is focused on finding them, clearing them, and solving them, and doing so with the same priority that comes with production.

June 15, 2009January 9, 2019

Get Specific

A couple of days ago I had an interesting session with an improvement team in a fairly large company. They have been working on this for almost 10 years, and believe that while they have made some spot progress, they are clear that they have spent a lot of money but not yet established what they call a “lean culture.” Their implied question was “How do we get there?”

My question was “When you say ‘a lean culture,’ exactly what are you thinking about?”

What do people do? How do they behave?

“People find and eliminate waste every day.”

OK, so if they were doing that, what would you see if you watched?

There was a bit of a struggle to articulate an answer.

I see this all of the time. We rely on the jargon or general statements to define the objective, without really digging down the next couple of layers and getting clear with ourselves about what the jargon means to us. This is especially the case when we are talking about the people side of the system.

But the people are the system. They are the ones who are in there every single day making it all happen. It is people who do all of the thinking.

Consider these steps:

Define Value.
Map your value streams.
Establish flow.
Pull the value through the value stream.
Seek perfection.

This is the implementation sequence from Lean Thinking by Womack, Jones and Roos, that has been the guideline for a generation+ of practitioners.

Learning to See taught that generation (and is teaching this one) to establish a current-state map of the value stream, and then a design the future state to implement as flow is established. The follow-on workbooks focused on establishing flow and pull, and did it very well.

While not the only way to go about this, it does work for most processes to establish flow in materials and information.

But what do people do every day to drive continuous improvement, and how are those efforts organized, harnessed, and captured to put the results where they can truly benefit customers and the business?

Here are some things to think about.

What exactly is the target condition for your organization? Can you describe what it will look like? Can you describe it in terms of what people experience, and do, every day?

When your people go home to their families and share what they did at work today, what will they talk about? And I don’t just mean the engineers and managers. What will the front-line value-creating people remember from the workday?

How will they talk about problems?

If your target future state now includes changes in how people work, ask yourself more questions.

When, exactly, are they going to do these things you described? By “when” I mean what time, starting when, ending when.

What, exactly, do they do when they encounter a problem during production?

How, exactly, do you expect the organization to respond to that problem? Who, exactly, is responsible to work through the issue and get things back on track? How long do they have to do it? If the problem is outside their scope, what is supposed to happen? How, exactly, does additional support get involved?

If these new activities involve new skills, when and how, exactly, are people supposed to learn them and practice them to get better at it? Who is supposed to teach them, when, where, and how? How will you verify that the new skills are being used, and are having the effect you intend?

“If we do this, what will happen?”

And then what? And then what?

Think it through.

The “people” future state is far more important than future state of the material and information flow.